home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr18 / pgp23.zip / PGPDOC2.DOC < prev    next >
Text File  |  1993-06-15  |  118KB  |  2,399 lines

  1.  
  2.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am              Page 1
  3.  
  4.  
  5.                           Phil's Pretty Good Software
  6.                                     Presents
  7.       
  8.                                       ===
  9.                                       PGP
  10.                                       ===
  11.       
  12.                               Pretty Good Privacy
  13.                       Public Key Encryption for the Masses
  14.       
  15.       
  16.                            -------------------------
  17.                                 PGP User's Guide
  18.                            Volume II: Special Topics
  19.                            -------------------------
  20.                               by Philip Zimmermann
  21.                                Revised 14 Jun 93
  22.       
  23.       
  24.                           PGP Version 2.3 - 13 Jun 93
  25.                                   Software by
  26.                                Philip Zimmermann
  27.                                       with
  28.                 Branko Lankester, Hal Finney, and Peter Gutmann
  29.       
  30.       
  31.       
  32.       
  33.      Synopsis:  PGP uses public-key encryption to protect E-mail and data
  34.      files.  Communicate securely with people you've never met, with no
  35.      secure channels needed for prior exchange of keys.  PGP is well
  36.      featured and fast, with sophisticated key management, digital
  37.      signatures, data compression, and good ergonomic design.
  38.       
  39.       
  40.      Software and documentation (c) Copyright 1990-1993 Philip Zimmermann. 
  41.      For information on PGP licensing, distribution, copyrights, patents,
  42.      trademarks, liability limitations, and export controls, see the
  43.      "Legal Issues" section.
  44.       
  45.       
  46.  
  47.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am              Page 2
  48.  
  49.  
  50.       
  51.      Contents
  52.      ========
  53.       
  54.      Quick Overview
  55.      Special Topics
  56.        Selecting Keys via Key ID
  57.        Separating Signatures from Messages
  58.        Decrypting the Message and Leaving the Signature on it
  59.        Sending ASCII Text Files Across Different Machine Environments
  60.        Leaving No Traces of Plaintext on the Disk
  61.        Displaying Decrypted Plaintext on Your Screen
  62.        Making a Message For Her Eyes Only
  63.        Preserving the Original Plaintext Filename
  64.        Editing Your User ID or Pass Phrase
  65.        Editing the Trust Parameters for a Public Key
  66.        Checking If Everything is OK on Your Public Key Ring
  67.        Verifying a Public Key Over the Phone
  68.        Using PGP as a Unix-style Filter
  69.        Suppressing Unneccessary Questions:  BATCHMODE
  70.        Force "Yes" Answer to Confirmation Questions:  FORCE
  71.        PGP Returns Exit Status to the Shell
  72.        Environmental Variable for Pass Phrase
  73.        Setting Configuration Parameters: CONFIG.TXT
  74.          TMP - Directory Pathname for Temporary Files
  75.          LANGUAGE - Foreign Language Selector
  76.          MYNAME - Default User ID for Making Signatures
  77.          TEXTMODE - Assuming Plaintext is a Text File
  78.          CHARSET - Specifies Local Character Set for Text Files
  79.          ARMOR - Enable ASCII Armor Output
  80.          ARMORLINES - Size of ASCII Armor Multipart Files
  81.          KEEPBINARY - Keep Binary Ciphertext Files After Decrypting
  82.          COMPRESS - Enable Compression
  83.          COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed
  84.          MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed
  85.          CERT_DEPTH - How Deep May Introducers Be Nested
  86.          BAKRING - Filename for Backup Secret Keyring
  87.          PAGER - Selects Shell Command to Display Plaintext Output
  88.          SHOWPASS - Echo Pass Phrase to User
  89.          TZFIX - Timezone Adjustment
  90.          CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text
  91.          VERBOSE - Quiet, Normal, or Verbose Messages
  92.          INTERACTIVE - Ask for Confirmation for Key Adds
  93.        Protecting Against Bogus Timestamps
  94.        A Peek Under the Hood
  95.          Random Numbers
  96.          PGP's Conventional Encryption Algorithm
  97.          Data Compression
  98.          Message Digests and Digital Signatures
  99.        Compatibility with Previous Versions of PGP
  100.      Vulnerabilities
  101.        Compromised Pass Phrase and Secret Key
  102.        Public Key Tampering
  103.        "Not Quite Deleted" Files
  104.        Viruses and Trojan Horses
  105.        Physical Security Breach
  106.  
  107.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am              Page 3
  108.  
  109.  
  110.        Tempest Attacks
  111.        Exposure on Multi-user Systems
  112.        Traffic Analysis
  113.        Cryptanalysis
  114.      Legal Issues
  115.        Trademarks, Copyrights, and Warranties
  116.        Patent Rights on the Algorithms
  117.        Licensing and Distribution
  118.        Export Controls
  119.      Computer-Related Political Groups
  120.      Recommended Readings
  121.      To Contact the Author
  122.      Appendix A:  Where to Get PGP
  123.       
  124.       
  125.  
  126.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am              Page 4
  127.  
  128.  
  129.       
  130.      Quick Overview
  131.      =============
  132.       
  133.      Pretty Good(tm) Privacy (PGP), from Phil's Pretty Good Software, is a
  134.      high security cryptographic software application for MSDOS, Unix,
  135.      VAX/VMS, and other computers.  PGP combines the convenience of the
  136.      Rivest-Shamir-Adleman (RSA) public key cryptosystem with the speed of
  137.      conventional cryptography, message digests for digital signatures,
  138.      data compression before encryption, good ergonomic design, and
  139.      sophisticated key management. 
  140.       
  141.      This volume II of the PGP User's Guide covers advanced topics about
  142.      PGP that were not covered in the "PGP User's Guide, Volume I:
  143.      Essential Topics".  You should first read the Essential Topics
  144.      volume, or this manual won't make much sense to you.  Reading this
  145.      Special Topics volume is optional.
  146.       
  147.       
  148.       
  149.      Special Topics
  150.      ===============
  151.       
  152.       
  153.      Selecting Keys via Key ID
  154.      -------------------------
  155.       
  156.      In all commands that let the user type a user ID or fragment of a
  157.      user ID to select a key, the hexadecimal key ID may be used instead. 
  158.      Just use the key ID, with a prefix of "0x", in place of the user ID. 
  159.      For example:
  160.       
  161.          pgp -kv 0x67F7
  162.       
  163.      This would display all keys that had 67F7 as part of their key IDs.
  164.       
  165.      This feature is particularly useful if you have two different keys
  166.      from the same person, with the same user ID.  You can unambiguously
  167.      pick which key you want by specifying the key ID.
  168.       
  169.       
  170.      Separating Signatures from Messages
  171.      -----------------------------------
  172.       
  173.      Normally, signature certificates are physically attached to the text
  174.      they sign.  This makes it convenient in simple cases to check
  175.      signatures.  It is desirable in some circumstances to have signature
  176.      certificates stored separately from the messages they sign.  It is
  177.      possible to generate signature certificates that are detached from
  178.      the text they sign.  To do this, combine the 'b' (break) option with
  179.      the 's' (sign) option.  For example:
  180.       
  181.          pgp -sb letter.txt
  182.       
  183.      This example produces an isolated signature certificate in a file
  184.      called "letter.sig".  The contents of letter.txt are not appended to
  185.  
  186.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am              Page 5
  187.  
  188.  
  189.      the signature certificate.
  190.       
  191.      After creating the signature certificate file (letter.sig in the
  192.      above example), send it along with the original text file to the
  193.      recipient.  The recipient must have both files to check the signature
  194.      integrity.  When the recipient attempts to process the signature
  195.      file, PGP notices that there is no text in the same file with the
  196.      signature and prompts the user for the filename of the text. Only
  197.      then can PGP properly check the signature integrity.  If the
  198.      recipient knows in advance that the signature is detached from the
  199.      text file, she can specify both filenames on the command line:
  200.       
  201.          pgp letter.sig letter.txt
  202.      or: pgp letter letter.txt
  203.       
  204.      PGP will not have to prompt for the text file name in this case.
  205.       
  206.      A detached signature certificate is useful if you want to keep the
  207.      signature certificate in a separate certificate log.  A detached
  208.      signature of an executable program is also useful for detecting a
  209.      subsequent virus infection.  It is also useful if more than one party
  210.      must sign a document such as a legal contract, without nesting
  211.      signatures.  Each person's signature is independent.
  212.       
  213.      If you receive a ciphertext file that has the signature certificate
  214.      glued to the message, you can still pry the signature certificate
  215.      away from the message during the decryption.  You can do this with
  216.      the -b option during decrypt, like so:
  217.       
  218.          pgp -b letter
  219.       
  220.      This decrypts the letter.pgp file and if there is a signature in it,
  221.      PGP checks the signature and detaches it from the rest of the
  222.      message, storing it in the file letter.sig.
  223.       
  224.       
  225.      Decrypting the Message and Leaving the Signature on it
  226.      ------------------------------------------------------
  227.       
  228.      Usually, you want PGP to completely unravel a ciphertext file,
  229.      decrypting it and checking the nested signature if there is one,
  230.      peeling away the layers until you are left with only the original
  231.      plaintext file.
  232.       
  233.      But sometimes you want to decrypt an encrypted file, and leave the
  234.      inner signature still attached, so that you are left with a decrypted
  235.      signed message.  This may be useful if you want to send a copy of a
  236.      signed document to a third party, perhaps re-enciphering it.  For
  237.      example, suppose you get a message signed by Charlie, encrypted to
  238.      you.  You want to decrypt it, and, leaving Charlie's signature on it,
  239.      you want to send it to Alice, perhaps re-enciphering it with Alice's
  240.      public key.  No problem.  PGP can handle that.
  241.       
  242.      To simply decrypt a message and leave the signature on it intact,
  243.      type:
  244.       
  245.  
  246.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am              Page 6
  247.  
  248.  
  249.          pgp -d letter
  250.       
  251.      This decrypts letter.pgp, and if there is an inner signature, it is
  252.      left intact with the decrypted plaintext in the output file.
  253.       
  254.      Now you can archive it, or maybe re-encrypt it and send it to someone
  255.      else.
  256.       
  257.       
  258.       
  259.      Sending ASCII Text Files Across Different Machine Environments
  260.      --------------------------------------------------------------
  261.       
  262.      You may use PGP to encrypt any kind of plaintext file, binary 8-bit
  263.      data or ASCII text.  Probably the most common usage of PGP will be for
  264.      E-mail, when the plaintext is ASCII text.  
  265.       
  266.      ASCII text is sometimes represented differently on different
  267.      machines.  For example, on an MSDOS system, all lines of ASCII text
  268.      are terminated with a carriage return followed by a linefeed.  On a
  269.      Unix system, all lines end with just a linefeed.  On a Macintosh, all
  270.      lines end with just a carriage return.  This is a sad fact of life.
  271.       
  272.      Normal unencrypted ASCII text messages are often automatically
  273.      translated to some common "canonical" form when they are transmitted
  274.      from one machine to another.  Canonical text has a carriage return
  275.      and a linefeed at the end of each line of text.  For example, the
  276.      popular KERMIT communication protocol can convert text to canonical
  277.      form when transmitting it to another system.  This gets converted
  278.      back to local text line terminators by the receiving KERMIT.  This
  279.      makes it easy to share text files across different systems.
  280.       
  281.      But encrypted text cannot be automatically converted by a
  282.      communication protocol, because the plaintext is hidden by
  283.      encipherment.  To remedy this inconvenience, PGP lets you specify
  284.      that the plaintext should be treated as ASCII text (not binary data)
  285.      and should be converted to canonical text form before it gets
  286.      encrypted.  At the receiving end, the decrypted plaintext is
  287.      automatically converted back to whatever text form is appropriate for
  288.      the local environment.
  289.       
  290.      To make PGP assume the plaintext is text that should be converted to
  291.      canonical text before encryption, just add the "t" option when
  292.      encrypting or signing a message, like so:
  293.       
  294.         pgp -et message.txt her_userid
  295.       
  296.      This mode is automatically turned off if PGP detects that the
  297.      plaintext file contains what it thinks is non-text binary data.
  298.       
  299.      For PGP users that use non-English 8-bit character sets, when PGP 
  300.      converts text to canonical form, it may convert data from the local
  301.      character set into the LATIN1 (ISO 8859-1 Latin Alphabet 1) character
  302.      set, depending on the setting of the CHARSET parameter in the PGP
  303.      configuration file.  LATIN1 is a superset of ASCII, with extra
  304.      characters added for many European languages.
  305.  
  306.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am              Page 7
  307.  
  308.  
  309.       
  310.       
  311.       
  312.      Leaving No Traces of Plaintext on the Disk
  313.      ------------------------------------------
  314.       
  315.      After PGP makes a ciphertext file for you, you can have PGP
  316.      automatically overwrite the plaintext file and delete it, leaving no
  317.      trace of plaintext on the disk so that no one can recover it later
  318.      using a disk block scanning utility.  This is useful if the plaintext
  319.      file contains sensitive information that you don't want to keep
  320.      around.
  321.       
  322.      To wipe out the plaintext file after producing the ciphertext file,
  323.      just add the "w" (wipe) option when encrypting or signing a message,
  324.      like so:
  325.       
  326.          pgp -esw message.txt her_userid
  327.       
  328.      This example creates the ciphertext file "message.pgp", and the 
  329.      plaintext file "message.txt" is destroyed beyond recovery.
  330.       
  331.      Obviously, you should be careful with this option.  Also note that
  332.      this will not wipe out any fragments of plaintext that your word
  333.      processor might have created on the disk while you were editing the
  334.      message before running PGP.  Most word processors create backup
  335.      files, scratch files, or both.  Also, it overwrites the file only
  336.      once, which is enough to thwart conventional disk recovery efforts,
  337.      but not enough to withstand a determined and sophisticated effort to
  338.      recover the faint magnetic traces of the data using special disk
  339.      recovery hardware.
  340.       
  341.       
  342.       
  343.      Displaying Decrypted Plaintext on Your Screen
  344.      ---------------------------------------------
  345.       
  346.      To view the decrypted plaintext output on your screen (like the
  347.      Unix-style "more" command), without writing it to a file, use the -m
  348.      (more) option while decrypting:
  349.       
  350.           pgp -m ciphertextfile
  351.       
  352.      This displays the decrypted plaintext display on your screen one
  353.      screenful at a time.
  354.       
  355.       
  356.       
  357.      Making a Message For Her Eyes Only
  358.      ----------------------------------
  359.       
  360.      To specify that the recipient's decrypted plaintext will be shown
  361.      ONLY on her screen and cannot be saved to disk, add the -m option:
  362.       
  363.           pgp -sem message.txt her_userid
  364.       
  365.  
  366.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am              Page 8
  367.  
  368.  
  369.      Later, when the recipient decrypts the ciphertext with her secret key
  370.      and pass phrase, the plaintext will be displayed on her screen but
  371.      will not be saved to disk.  The text will be displayed as it would if
  372.      she used the Unix "more" command, one screenful at a time.  If she
  373.      wants to read the message again, she will have to decrypt the
  374.      ciphertext again.
  375.       
  376.      This feature is the safest way for you to prevent your sensitive
  377.      message from being inadvertently left on the recipient's disk.  This
  378.      feature was added at the request of a user who wanted to send
  379.      intimate messages to his lover, but was afraid she might accidentally
  380.      leave the decrypted messages on her husband's computer.
  381.       
  382.       
  383.       
  384.      Preserving the Original Plaintext Filename
  385.      ------------------------------------------
  386.       
  387.      Normally, PGP names the decrypted plaintext output file with a name
  388.      similar to the input ciphertext filename, but dropping the 
  389.      extension.  Or, you can override that convention by specifying an
  390.      output plaintext filename on the command line with the -o option.
  391.      For most E-mail, this is a reasonable way to name the plaintext file,
  392.      because you get to decide its name when you decipher it, and your
  393.      typical E-mail messages often come from useless original plaintext
  394.      filenames like "to_phil.txt".  
  395.       
  396.      But when PGP encrypts a plaintext file, it always saves the original
  397.      filename and attaches it to the plaintext before it compresses and
  398.      encrypts the plaintext.  Normally, this hidden original filename is
  399.      discarded by PGP when it decrypts, but you can tell PGP you want to
  400.      preserve the original plaintext filename and use it as the name of
  401.      the decrypted plaintext output file.  This is useful if PGP is used
  402.      on files whose names are important to preserve.
  403.       
  404.      To recover the original plaintext filename while decrypting, add 
  405.      the -p option, like so:
  406.       
  407.           pgp -p ciphertextfile
  408.       
  409.      I usually don't use this option, because if I did, about half of my
  410.      incoming E-mail would decrypt to the same plaintext filenames of
  411.      "to_phil.txt" or "prz.txt".
  412.       
  413.       
  414.       
  415.      Editing Your User ID or Pass Phrase
  416.      -----------------------------------
  417.       
  418.      Sometimes you may need to change your pass phrase, perhaps because
  419.      someone looked over your shoulder while you typed it in.  
  420.       
  421.      Or you may need to change your user ID, because you got married and
  422.      changed your name, or maybe you changed your E-mail address.  Or
  423.      maybe you want to add a second or third user ID to your key, because
  424.      you may be known by more than one name or E-mail address or job
  425.  
  426.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am              Page 9
  427.  
  428.  
  429.      title.  PGP lets you attach more than one user ID to your key, any
  430.      one of which may be used to look up your key on the key ring.
  431.       
  432.      To edit your own userid or pass phrase for your secret key:
  433.       
  434.           pgp -ke userid [keyring]
  435.       
  436.      PGP prompts you for a new user ID or a new pass phrase.
  437.       
  438.      The optional [keyring] parameter, if specified, must be a public
  439.      keyring, not a secret keyring.  The userid field must be your own
  440.      userid, which PGP knows is yours because it appears on both your
  441.      public keyring and your secret keyring.  Both keyrings will be
  442.      updated, even though you only specified the public keyring.
  443.       
  444.       
  445.       
  446.      Editing the Trust Parameters for a Public Key
  447.      ---------------------------------------------
  448.       
  449.      Sometimes you need to alter the trust parameters for a public key on
  450.      your public key ring.  For a discussion on what these trust
  451.      parameters mean, see the section "How Does PGP Keep Track of Which
  452.      Keys are Valid?" in the Essential Topics volume of the PGP User's
  453.      Guide.
  454.       
  455.      To edit the trust parameters for a public key:
  456.       
  457.           pgp -ke userid [keyring]
  458.       
  459.      The optional [keyring] parameter, if specified, must be a public
  460.      keyring, not a secret keyring.
  461.       
  462.       
  463.       
  464.      Checking If Everything is OK on Your Public Key Ring
  465.      ----------------------------------------------------
  466.       
  467.      Normally, PGP automatically checks any new keys or signatures on your
  468.      public key ring and updates all the trust parameters and validity
  469.      scores.  In theory, it keeps all the key validity status information
  470.      up to date as material is added to or deleted from your public key
  471.      ring.  But perhaps you may want to explicitly force PGP to perform a
  472.      comprehensive analysis of your public key ring, checking all the
  473.      certifying signatures, checking the trust parameters, updating all
  474.      the validity scores, and checking your own ultimately-trusted key
  475.      against a backup copy on a write-protected floppy disk.  It may be a
  476.      good idea to do this hygienic maintenance periodically to make sure
  477.      nothing is wrong with your public key ring.  To force PGP to perform
  478.      a full analysis of your public key ring, use the -kc (key ring check)
  479.      command:
  480.       
  481.           pgp -kc
  482.       
  483.      You can also make PGP check all the signatures for just a single
  484.      selected public key by:
  485.  
  486.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 10
  487.  
  488.  
  489.       
  490.           pgp -kc userid [keyring]
  491.       
  492.      For further information on how the backup copy of your own key is
  493.      checked, see the description of the BAKRING parameter in the
  494.      configuration file section of this manual.
  495.       
  496.       
  497.       
  498.      Verifying a Public Key Over the Phone
  499.      -------------------------------------
  500.       
  501.      If you get a public key from someone that is not certified by anyone
  502.      you trust, how can you tell if it's really their key?  The best way
  503.      to verify an uncertified key is to verify it over some independent
  504.      channel other than the one you received the key through.  One
  505.      convenient way to tell, if you know this person and would recognize
  506.      them on the phone, is to call them and verify their key over the
  507.      telephone.  Rather than reading their whole tiresome (ASCII-armored)
  508.      key to them over the phone, you can just read their key's
  509.      "fingerprint" to them.  To see this fingerprint, use the -kvc
  510.      command:
  511.       
  512.           pgp -kvc userid [keyring]
  513.       
  514.      This will display the key with the 16-byte digest of the public key
  515.      components.  Read this 16-byte fingerprint to the key's owner on the
  516.      phone, while she checks it against her own, using the same -kvc
  517.      command at her end.  
  518.       
  519.      You can both verify each other's keys this way, and then you can sign
  520.      each other's keys with confidence.  This is a safe and convenient way
  521.      to get the key trust network started for your circle of friends.
  522.       
  523.       
  524.       
  525.      Using PGP as a Unix-style Filter
  526.      --------------------------------
  527.       
  528.      Unix fans are accustomed to using Unix "pipes" to make two
  529.      applications work together.  The output of one application can be
  530.      directly fed through a pipe to be read as input to another
  531.      application.  For this to work, the applications must be capable of
  532.      reading the raw material from "standard input" and writing the
  533.      finished output to "standard output".  PGP can operate in this mode.
  534.      If you don't understand what this means, then you probably don't need
  535.      this feature.
  536.       
  537.      To use a Unix-style filter mode, reading from standard input and
  538.      writing to standard output, add the -f option, like so:
  539.       
  540.           pgp -feast her_userid <inputfile >outputfile
  541.       
  542.      This feature makes it easier to make PGP work with electronic mail
  543.      applications.
  544.       
  545.  
  546.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 11
  547.  
  548.  
  549.      When using PGP in filter mode to decrypt a ciphertext file, you may
  550.      find it useful to use the PGPPASS environmental variable to hold the
  551.      pass phrase, so that you won't be prompted for it.  The PGPPASS
  552.      feature is explained below.
  553.       
  554.       
  555.       
  556.      Suppressing Unneccessary Questions:  BATCHMODE
  557.      ----------------------------------------------
  558.       
  559.      With the BATCHMODE flag enabled on the command line, PGP will not ask
  560.      any unneccessary questions or prompt for alternate filenames.  Here
  561.      is an example of how to set this flag:
  562.       
  563.          pgp +batchmode cipherfile 
  564.       
  565.      This is useful for running PGP non-interactively from Unix shell
  566.      scripts or MSDOS batch files.  Some key management commands still
  567.      need user interaction even when BATCHMODE is on, so shell scripts may
  568.      need to avoid them.  
  569.       
  570.      BATCHMODE may also be enabled to check the validity of a signature on
  571.      a file.  If there was no signature on the file, the exit code is 1. 
  572.      If it had a signature that was good, the exit code is 0.
  573.       
  574.       
  575.      Force "Yes" Answer to Confirmation Questions:  FORCE
  576.      ----------------------------------------------------
  577.       
  578.      This command-line flag makes PGP assume "yes" for the user response
  579.      to the confirmation request to overwrite an existing file, or when
  580.      removing a key from the keyring via the -kr command.  Here is an
  581.      example of how to set this flag:
  582.       
  583.          pgp +force cipherfile 
  584.      or:
  585.          pgp -kr +force Smith
  586.       
  587.      This feature is useful for running PGP non-interactively from a Unix
  588.      shell script or MSDOS batch file.
  589.       
  590.       
  591.       
  592.      PGP Returns Exit Status to the Shell
  593.      ------------------------------------
  594.       
  595.      To facilitate running PGP in "batch" mode, such as from an MSDOS
  596.      ".bat" file or from a Unix shell script, PGP returns an error exit
  597.      status to the shell.  An exit status code of zero means normal exit,
  598.      while a nonzero exit status indicates some kind of error occurred.
  599.      Different error exit conditions return different exit status codes to
  600.      the shell.
  601.       
  602.       
  603.       
  604.      Environmental Variable for Pass Phrase
  605.  
  606.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 12
  607.  
  608.  
  609.      --------------------------------------
  610.       
  611.      Normally, PGP prompts the user to type a pass phrase whenever PGP 
  612.      needs a pass phrase to unlock a secret key.  But it is possible to
  613.      store the pass phrase in an environmental variable from your
  614.      operating system's command shell.  The environmental variable PGPPASS
  615.      can be used to hold the pass phrase that PGP will attempt to use
  616.      first.  If the pass phrase stored in PGPPASS is incorrect, PGP 
  617.      recovers by prompting the user for the correct pass phrase.
  618.       
  619.      For example, on MSDOS, the shell command:
  620.       
  621.          SET PGPPASS=zaphod beeblebrox for president
  622.       
  623.      would eliminate the prompt for the pass phrase if the pass phrase
  624.      were indeed "zaphod beeblebrox for president". 
  625.       
  626.      This dangerous feature makes your life more convenient if you have to
  627.      regularly deal with a large number of incoming messages addressed to
  628.      your secret key, by eliminating the need for you to repeatedly type
  629.      in your pass phrase every time you run PGP.
  630.       
  631.      I added this feature because of popular demand.  However, this is a
  632.      somewhat dangerous feature, because it keeps your precious pass
  633.      phrase stored somewhere other than just in your brain.  Even worse,
  634.      if you are particularly reckless, it may even be stored on a disk on
  635.      the same computer as your secret key.  It would be particularly
  636.      dangerous and stupid if you were to install this command in a batch
  637.      or script file, such as the MSDOS AUTOEXEC.BAT file.  Someone could
  638.      come along on your lunch hour and steal both your secret key ring and
  639.      the file containing your pass phrase.  
  640.       
  641.      I can't emphasize the importance of this risk enough.  If you are
  642.      contemplating using this feature, be sure to read the sections
  643.      "Exposure on Multi-user Systems" and "How to Protect Secret Keys from
  644.      Disclosure" in this volume and in the Essential Topics volume of the 
  645.      PGP User's Guide.
  646.       
  647.      If you must use this feature, the safest way to do it would be to
  648.      just manually type in the shell command to set PGPPASS every time you
  649.      boot your machine to start using PGP, and then erase it or turn off
  650.      your machine when you are done.  And you should definitely never do
  651.      it in an environment where someone else may have access to your
  652.      machine.  Someone could come along and simply ask your computer to
  653.      display the contents of PGPPASS.
  654.       
  655.       
  656.       
  657.      Setting Configuration Parameters: CONFIG.TXT
  658.      ============================================
  659.       
  660.      PGP has a number of user-settable parameters that can be defined in a
  661.      special configuration text file called "config.txt", in the directory
  662.      pointed to by the shell environmental variable PGPPATH.  Having a
  663.      configuration file enables the user to define various flags and
  664.      parameters for PGP without the burden of having to always define
  665.  
  666.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 13
  667.  
  668.  
  669.      these parameters in the PGP command line.
  670.       
  671.      Configuration parameters may be assigned integer values, character
  672.      string values, or on/off values, depending on what kind of
  673.      configuration parameter it is.  A sample configuration file is
  674.      provided with PGP, so you can see some examples.
  675.       
  676.      In the configuration file, blank lines are ignored, as is anything
  677.      following the '#' comment character.  Keywords are not
  678.      case-sensitive.  
  679.       
  680.      Here is a short sample fragment of a typical configuration file:
  681.       
  682.         # TMP is the directory for PGP scratch files, such as a RAM disk.
  683.         TMP = "e:\"    # Can be overridden by environment variable TMP.
  684.         Armor = on     # Use -a flag for ASCII armor whenever applicable.
  685.         # CERT_DEPTH is how deeply introducers may introduce introducers.
  686.         cert_depth = 3
  687.       
  688.      If some configuration parameters are not defined in the configuration
  689.      file, or if there is no configuration file, or if PGP can't find the
  690.      configuration file, the values for the configuration parameters
  691.      default to some reasonable value.
  692.       
  693.      Note that it is also possible to set these same configuration
  694.      parameters directly from the PGP command line, by preceding the
  695.      parameter setting with a "+" character.  For example, the following
  696.      two PGP commands produce the same effect:
  697.       
  698.           pgp -e +armor=on message.txt smith
  699.      or:  pgp -ea message.txt smith
  700.       
  701.       
  702.      The following is a summary of the various parameters than may be
  703.      defined in the configuration file.
  704.       
  705.       
  706.      TMP - Directory Pathname for Temporary Files
  707.      --------------------------------------------
  708.       
  709.      Default setting:  TMP = ""
  710.       
  711.      The configuration parameter TMP specifies what directory to use for
  712.      PGP's temporary scratch files.  The best place to put them is on a
  713.      RAM disk, if you have one.  That speeds things up quite a bit, and
  714.      increases security somewhat.  If TMP is undefined, the temporary
  715.      files go in the current directory.  If the shell environmental
  716.      variable TMP is defined, PGP instead uses that to specify where the
  717.      temporary files should go.
  718.       
  719.       
  720.      LANGUAGE - Foreign Language Selector
  721.      ------------------------------------
  722.       
  723.      Default setting:  LANGUAGE = "en"
  724.       
  725.  
  726.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 14
  727.  
  728.  
  729.      PGP displays various prompts, warning messages, and advisories to the
  730.      user on the screen.  For example, messages such as "File not found.",
  731.      or "Please enter your pass phrase:".  These messages are normally in
  732.      English.  But it is possible to get PGP to display its messages to
  733.      the user in other languages, without having to modify the PGP
  734.      executable program.
  735.       
  736.      A number of people in various countries have translated all of PGP's
  737.      display messages, warnings, and prompts into their native languages. 
  738.      These hundreds of translated message strings have been placed in a
  739.      special text file called "language.txt", distributed with the PGP
  740.      release.  The messages are stored in this file in English, Spanish,
  741.      Dutch, German, French, Italian, Russian, Latvian, and Lithuanian. 
  742.      Other languages may be added later.  
  743.       
  744.      The configuration parameter LANGUAGE specifies what language to
  745.      display these messages in.  LANGUAGE may be set to "en" for English,
  746.      "es" for Spanish, "de" for German, "nl" for Dutch, "fr" for French,
  747.      "it" for Italian, "ru" for Russian, "lt3" for Lithuanian, "lv" for
  748.      Latvian, "esp" for Esperanto.  For example, if this line appeared in
  749.      the configuration file:
  750.       
  751.         LANGUAGE = "fr"
  752.       
  753.      PGP would select French as the language for its display messages.
  754.      The default setting is English.
  755.       
  756.      When PGP needs to display a message to the user, it looks in the
  757.      "language.txt" file for the equivalent message string in the selected
  758.      foreign language and displays that translated message to the user.
  759.      If PGP can't find the language string file, or if the selected
  760.      language is not in the file, or if that one phrase is not translated
  761.      into the selected language in the file, or if that phrase is missing
  762.      entirely from the file, PGP displays the message in English.
  763.       
  764.      To conserve disk space, most foreign translations are not included 
  765.      in the standard PGP release package, but are available separately.
  766.       
  767.       
  768.      MYNAME - Default User ID for Making Signatures
  769.      ----------------------------------------------
  770.       
  771.      Default setting:  MYNAME = ""
  772.       
  773.      The configuration parameter MYNAME specifies the default user ID to
  774.      use to select the secret key for making signatures.  If MYNAME is not
  775.      defined, the most recent secret key you installed on your secret key
  776.      ring will be used.  The user may also override this setting by
  777.      specifying a user ID on the PGP command line with the -u option.
  778.       
  779.       
  780.      TEXTMODE - Assuming Plaintext is a Text File
  781.      --------------------------------------------
  782.       
  783.      Default setting:  TEXTMODE = off
  784.       
  785.  
  786.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 15
  787.  
  788.  
  789.      The configuration parameter TEXTMODE is equivalent to the -t command
  790.      line option.  If enabled, it causes PGP to assume the plaintext is a
  791.      text file, not a binary file, and converts it to "canonical text"
  792.      before encrypting it.  Canonical text has a carriage return and a
  793.      linefeed at the end of each line of text.
  794.       
  795.      This mode will be automatically turned off if PGP detects that the
  796.      plaintext file contains what it thinks is non-text binary data.
  797.       
  798.      For VAX/VMS systems, the current version of PGP defaults TEXTMODE=ON.
  799.       
  800.      For further details, see the section "Sending ASCII Text Files Across
  801.      Different Machine Environments".
  802.       
  803.       
  804.      CHARSET - Specifies Local Character Set for Text Files
  805.      ------------------------------------------------------
  806.       
  807.      Default setting:  CHARSET = NOCONV
  808.       
  809.      Because PGP must process messages in many non-English languages with
  810.      non-ASCII character sets, you may have a need to tell PGP what local
  811.      character set your machine uses.  This determines what character
  812.      conversions are performed when converting plaintext files to and from
  813.      canonical text format.  This is only a concern if you are in a
  814.      non-English non-ASCII environment.
  815.       
  816.      The configuration parameter CHARSET selects the local character set. 
  817.      The choices are NOCONV (no conversion), LATIN1 (ISO 8859-1 Latin
  818.      Alphabet 1), KOI8 (used by most Russian Unix systems), ALT_CODES
  819.      (used by Russian MSDOS systems), ASCII, and CP850 (used by most
  820.      western European languages on standard MSDOS PCs).
  821.       
  822.      LATIN1 is the internal representation used by PGP for canonical text,
  823.      so if you select LATIN1, no conversion is done.  Note also that PGP
  824.      treats KOI8 as LATIN1, even though it is a completely different
  825.      character set (Russian), because trying to convert KOI8 to either
  826.      LATIN1 or CP850 would be futile anyway.  This means that setting
  827.      CHARSET to NOCONV, LATIN1, or KOI8 are all equivalent to PGP.
  828.       
  829.      If you use MSDOS and expect to send or receive traffic in western
  830.      European languages, set CHARSET = "CP850".  This will make PGP
  831.      convert incoming canonical text messages from LATIN1 to CP850 after
  832.      decryption.  If you use the -t (textmode) option to convert to
  833.      canonical text, PGP will convert your CP850 text to LATIN1 before
  834.      encrypting it.
  835.       
  836.      For further details, see the section "Sending ASCII Text Files Across
  837.      Different Machine Environments".
  838.       
  839.       
  840.      ARMOR - Enable ASCII Armor Output
  841.      ---------------------------------
  842.       
  843.      Default setting:  ARMOR = off
  844.       
  845.  
  846.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 16
  847.  
  848.  
  849.      The configuration parameter ARMOR is equivalent to the -a command
  850.      line option.  If enabled, it causes PGP to emit ciphertext or keys in
  851.      ASCII Radix-64 format suitable for transporting through E-mail
  852.      channels.  Output files are named with the ".asc" extension.
  853.       
  854.      If you tend to use PGP mostly for E-mail, it may be a good idea to
  855.      enable this parameter.
  856.       
  857.      For further details, see the section "Sending Ciphertext Through
  858.      E-mail Channels: Radix-64 Format" in the Essential Topics volume. 
  859.       
  860.       
  861.      ARMORLINES - Size of ASCII Armor Multipart Files
  862.      ------------------------------------------------
  863.       
  864.      Default setting:  ARMORLINES = 720
  865.       
  866.      When PGP creates a very large ".asc" radix-64 file for sending
  867.      ciphertext or keys through the E-mail, it breaks the file up into
  868.      separate chunks small enough to send through Internet mail
  869.      utilities.  Normally, Internet mailers prohibit files larger than
  870.      about 50000 bytes, which means that if we restrict the number of
  871.      lines to about 720, we'll be well within the limit.  The file chunks
  872.      are named with suffixes ".as1", ".as2", ".as3", ... 
  873.       
  874.      The configuration parameter ARMORLINES specifies the maximum number
  875.      of lines to make each chunk in a multipart ".asc" file sequence.  If
  876.      you set it to zero, PGP will not break up the file into chunks.
  877.       
  878.      Fidonet email files usually have an upper limit of about 32K bytes,
  879.      so 450 lines would be appropriate for Fidonet environments.
  880.       
  881.      For further details, see the section "Sending Ciphertext Through
  882.      E-mail Channels: Radix-64 Format" in the Essential Topics volume.
  883.       
  884.       
  885.      KEEPBINARY - Keep Binary Ciphertext Files After Decrypting
  886.      ----------------------------------------------------------
  887.       
  888.      Default setting:  KEEPBINARY = off
  889.       
  890.      When PGP reads a ".asc" file, it recognizes that the file is in
  891.      radix-64 format and will convert it back to binary before processing
  892.      as it normally does, producing as a by-product a ".pgp" ciphertext
  893.      file in binary form.  After further processing to decrypt the ".pgp"
  894.      file, the final output file will be in normal plaintext form.
  895.       
  896.      You may want to delete the binary ".pgp" intermediate file, or you
  897.      may want PGP to delete it for you automatically.  You can still rerun
  898.      PGP on the original ".asc" file.
  899.       
  900.      The configuration parameter KEEPBINARY enables or disables keeping
  901.      the intermediate ".pgp" file during decryption.
  902.       
  903.      For further details, see the section "Sending Ciphertext Through
  904.      E-mail Channels: Radix-64 Format" in the Essential Topics volume.
  905.  
  906.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 17
  907.  
  908.  
  909.       
  910.       
  911.      COMPRESS - Enable Compression
  912.      -----------------------------
  913.       
  914.      Default setting:  COMPRESS = on
  915.       
  916.      The configuration parameter COMPRESS enables or disables data
  917.      compression before encryption.  It is used mainly for debugging PGP. 
  918.      Normally, PGP attempts to compress the plaintext before it encrypts
  919.      it.  Generally, you should leave this alone and let PGP attempt to
  920.      compress the plaintext.
  921.       
  922.       
  923.      COMPLETES_NEEDED - Number of Completely Trusted Introducers Needed
  924.      ------------------------------------------------------------------
  925.       
  926.      Default setting:  COMPLETES_NEEDED = 1
  927.       
  928.      The configuration parameter COMPLETES_NEEDED specifies the minimum
  929.      number of completely trusted introducers required to fully certify a
  930.      public key on your public key ring.  This gives you a way of tuning
  931.      PGP's skepticism.
  932.       
  933.      For further details, see the section "How Does PGP Keep Track of 
  934.      Which Keys are Valid?" in the Essential Topics volume.
  935.       
  936.       
  937.      MARGINALS_NEEDED - Number of Marginally Trusted Introducers Needed
  938.      ------------------------------------------------------------------
  939.       
  940.      Default setting:  MARGINALS_NEEDED = 2
  941.       
  942.      The configuration parameter MARGINALS_NEEDED specifies the minimum
  943.      number of marginally trusted introducers required to fully certify a
  944.      public key on your public key ring.  This gives you a way of tuning
  945.      PGP's skepticism.
  946.       
  947.      For further details, see the section "How Does PGP Keep Track of 
  948.      Which Keys are Valid?" in the Essential Topics volume.
  949.       
  950.       
  951.      CERT_DEPTH - How Deep May Introducers Be Nested
  952.      -----------------------------------------------
  953.       
  954.      Default setting:  CERT_DEPTH = 4
  955.       
  956.      The configuration parameter CERT_DEPTH specifies how many levels deep
  957.      you may nest introducers to certify other introducers to certify
  958.      public keys on your public key ring.  For example, If CERT_DEPTH is
  959.      set to 1, there may only be one layer of introducers below your own
  960.      ultimately-trusted key.  If that were the case, you would be required
  961.      to directly certify the public keys of all trusted introducers on
  962.      your key ring.  If you set CERT_DEPTH to 0, you could have no
  963.      introducers at all, and you would have to directly certify each and
  964.      every key on your public key ring in order to use it.  The minimum
  965.  
  966.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 18
  967.  
  968.  
  969.      CERT_DEPTH is 0, the maximum is 8.
  970.       
  971.      For further details, see the section "How Does PGP Keep Track of 
  972.      Which Keys are Valid?" in the Essential Topics volume.
  973.       
  974.       
  975.      BAKRING - Filename for Backup Secret Keyring
  976.      --------------------------------------------
  977.       
  978.      Default setting:  BAKRING = ""
  979.       
  980.      All of the key certification that PGP does on your public key ring
  981.      ultimately depends on your own ultimately-trusted public key (or
  982.      keys).  To detect any tampering of your public key ring, PGP must
  983.      check that your own key has not been tampered with.  To do this, PGP
  984.      must compare your public key against a backup copy of your secret key
  985.      on some tamper-resistant media, such as a write-protected floppy
  986.      disk.  A secret key contains all the information that your public key
  987.      has, plus some secret components.  This means PGP can check your
  988.      public key against a backup copy of your secret key.
  989.       
  990.      The configuration parameter BAKRING specifies what pathname to use
  991.      for PGP's trusted backup copy of your secret key ring.  On MSDOS, you
  992.      could set it to "a:\secring.pgp" to point it at a write-protected
  993.      backup copy of your secret key ring on your floppy drive.  This check
  994.      is performed only when you execute the PGP -kc option to check your
  995.      whole public key ring.
  996.       
  997.      If BAKRING is not defined, PGP will not check your own key against
  998.      any backup copy.
  999.       
  1000.      For further details, see the sections "How to Protect Public Keys
  1001.      from Tampering" and "How Does PGP Keep Track of Which Keys are
  1002.      Valid?" in the Essential Topics volume.
  1003.       
  1004.       
  1005.      PAGER - Selects Shell Command to Display Plaintext Output
  1006.      ---------------------------------------------------------
  1007.       
  1008.      Default setting:  PAGER = ""
  1009.       
  1010.      PGP lets you view the decrypted plaintext output on your screen (like
  1011.      the Unix-style "more" command), without writing it to a file, if you
  1012.      use the -m (more) option while decrypting.  This displays the
  1013.      decrypted plaintext display on your screen one screenful at a time.
  1014.       
  1015.      If you prefer to use a fancier page display utility, rather than
  1016.      PGP's built-in one, you can specify the name of a shell command that
  1017.      PGP will invoke to display your plaintext output file.  The
  1018.      configuration parameter PAGER specifies the shell command to invoke
  1019.      to display the file.  For example, on MSDOS systems, you might want
  1020.      to use the popular shareware program "list.com" to display your
  1021.      plaintext message.  Assuming you have a copy of "list.com", you may 
  1022.      set PAGER accordingly:
  1023.       
  1024.         PAGER = "list"
  1025.  
  1026.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 19
  1027.  
  1028.  
  1029.       
  1030.      However, if the sender specified that this file is for your eyes
  1031.      only, and may not be written to disk, PGP always uses its own
  1032.      built-in display function.
  1033.       
  1034.      For further details, see the section "Displaying Decrypted Plaintext 
  1035.      on Your Screen".
  1036.       
  1037.       
  1038.      SHOWPASS - Echo Pass Phrase to User
  1039.      -----------------------------------
  1040.       
  1041.      Default setting:  SHOWPASS = off
  1042.       
  1043.      Normally, PGP does not let you see your pass phrase as you type it
  1044.      in.  This makes it harder for someone to look over your shoulder
  1045.      while you type and learn your pass phrase.  But some typing-impaired
  1046.      people have problems typing their pass phrase without seeing what
  1047.      they are typing, and they may be typing in the privacy of their own
  1048.      homes.  So they asked if PGP can be configured to let them see what
  1049.      they type when they type in their pass phrase.
  1050.       
  1051.      The configuration parameter SHOWPASS enables PGP to echo your typing 
  1052.      during pass phrase entry.
  1053.       
  1054.       
  1055.      TZFIX - Timezone Adjustment
  1056.      ---------------------------
  1057.       
  1058.      Default setting:  TZFIX = 0
  1059.       
  1060.      PGP provides timestamps for keys and signature certificates in
  1061.      Greenwich Mean Time (GMT), or Coordinated Universal Time (UTC), which
  1062.      means the same thing for our purposes.  When PGP asks the system for
  1063.      the time of day, the system is supposed to provide it in GMT.  
  1064.       
  1065.      But sometimes, because of improperly configured MSDOS systems, the
  1066.      system time is returned in US Pacific Standard Time time plus 8
  1067.      hours.  Sounds weird, doesn't it?  Perhaps because of some sort of US
  1068.      west-coast jingoism, MSDOS presumes local time is US Pacific time,
  1069.      and pre-corrects Pacific time to GMT.  This adversely affects the
  1070.      behavior of the internal MSDOS GMT time function that PGP calls. 
  1071.      However, if your MSDOS environmental variable TZ is already properly
  1072.      defined for your timezone, this corrects the misconception MSDOS has
  1073.      that the whole world lives on the US west coast.  
  1074.       
  1075.      The configuration parameter TZFIX specifies the number of hours to
  1076.      add to the system time function to get GMT, for GMT timestamps on
  1077.      keys and signatures.  If the MSDOS environmental variable TZ is
  1078.      defined properly, you can leave TZFIX=0.  Unix systems usually
  1079.      shouldn't need to worry about setting TZFIX at all.  But if you are
  1080.      using some other obscure operating system that doesn't know about
  1081.      GMT, you may have to use TZFIX to adjust the system time to GMT. 
  1082.       
  1083.      On MSDOS systems that do not have TZ defined in the environment, you
  1084.      should make TZFIX=0 for California, -1 for Colorado, -2 for Chicago,
  1085.  
  1086.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 20
  1087.  
  1088.  
  1089.      -3 for New York, -8 for London, -9 for Amsterdam.  In the summer,
  1090.      TZFIX should be manually decremented from these values.  What a mess.
  1091.       
  1092.      It would be much cleaner to set your MSDOS environmental variable TZ
  1093.      in your AUTOEXEC.BAT file, and not use the TZFIX correction.  Then
  1094.      MSDOS gives you good GMT timestamps, and will handle daylight savings
  1095.      time adjustments for you.  Here are some sample lines to insert into
  1096.      AUTOEXEC.BAT, depending on your time zone:
  1097.       
  1098.      For Los Angeles:  SET TZ=PST8PDT
  1099.      For Denver:       SET TZ=MST7MDT
  1100.      For Arizona:      SET TZ=MST7
  1101.         (Arizona never uses daylight savings time)
  1102.      For Chicago:      SET TZ=CST6CDT
  1103.      For New York:     SET TZ=EST5EDT
  1104.      For London:       SET TZ=GMT0BST
  1105.      For Amsterdam:    SET TZ=MET-1DST
  1106.      For Moscow:       SET TZ=MSK-3MSD
  1107.      For Aukland:      SET TZ=NZT-13
  1108.       
  1109.       
  1110.      CLEARSIG - Enable Signed Messages to be Encapsulated as Clear Text
  1111.      ------------------------------------------------------------------
  1112.       
  1113.      Default setting:  CLEARSIG = off
  1114.       
  1115.      Normally, unencrypted PGP signed messages have a signature
  1116.      certificate prepended in binary form.  To send this through a 7-bit
  1117.      E-mail channel, radix-64 ASCII armor is applied (see the ARMOR
  1118.      parameter), rendering the message unreadable to casual human eyes,
  1119.      even though the message is not actually encrypted.  The recipient
  1120.      must use PGP to strip the armor off before reading the message.
  1121.       
  1122.      If the original plaintext message is in text (not binary) form, there
  1123.      is a way to send it through an E-mail channel in such a way that the
  1124.      ASCII armor is applied only to the binary signature certificate, but
  1125.      not to the plaintext message.  This makes it possible to read the
  1126.      signed message with human eyes, without the aid of PGP.  Of course,
  1127.      you still need PGP to actually check the signature.
  1128.       
  1129.      To enable this feature, set CLEARSIG=ON, and set ARMOR=ON (or use
  1130.      the -a option), and set TEXTMODE=ON (or use the -t option).  For
  1131.      example, you can set CLEARSIG directly from the command line:
  1132.       
  1133.           pgp -sta +clearsig=on message.txt
  1134.       
  1135.      This message representation is analogous to the MIC-CLEAR message type
  1136.      used in Internet Privacy Enhanced Mail (PEM).  It is important to
  1137.      note that since this method only applies ASCII armor to the binary
  1138.      signature certificate, and not to the message text itself, there is
  1139.      some risk that the unarmored message may suffer some accidental
  1140.      molestation while en route.  This can happen if it passes through
  1141.      some E-mail gateway that performs character set conversions, or in
  1142.      some cases extra spaces may be added to or stripped from the ends of
  1143.      lines.  If this occurs, the signature will fail to verify, which may
  1144.      give a false indication of intentional tampering.  But since PEM
  1145.  
  1146.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 21
  1147.  
  1148.  
  1149.      lives under a similar vulnerability, it seems worth having this
  1150.      feature despite the risks.
  1151.       
  1152.      Beginning with PGP version 2.2, trailing blanks are ignored on each
  1153.      line in calculating the signature for text in CLEARSIG mode.
  1154.       
  1155.       
  1156.      VERBOSE - Quiet, Normal, or Verbose Messages
  1157.      --------------------------------------------
  1158.       
  1159.      Default setting:  VERBOSE = 1
  1160.       
  1161.      VERBOSE may be set to 0, 1, or 2, depending on how much detail you
  1162.      want to see from PGP diagnostic messages.  The settings are:
  1163.       
  1164.      0 - Display messages only if there is a problem.  Unix fans wanted
  1165.      this "quiet mode" setting.
  1166.       
  1167.      1 - Normal default setting.  Displays a reasonable amount of detail
  1168.      in diagnostic or advisory messages.
  1169.       
  1170.      2 - Displays maximum information, usually to help diagnose problems
  1171.      in PGP.  Not recommended for normal use.  Besides, PGP doesn't have
  1172.      any problems, right?
  1173.       
  1174.       
  1175.      INTERACTIVE - Ask for Confirmation for Key Adds
  1176.      -----------------------------------------------
  1177.       
  1178.      Default Setting:  INTERACTIVE = off
  1179.       
  1180.      Enabling this mode will mean that if you add a key file containing
  1181.      multiple keys to your key ring, PGP will ask for confirmation for
  1182.      each key before adding it to your key ring.
  1183.       
  1184.       
  1185.       
  1186.  
  1187.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 22
  1188.  
  1189.  
  1190.       
  1191.      Protecting Against Bogus Timestamps
  1192.      ===================================
  1193.       
  1194.      A somewhat obscure vulnerability of PGP involves dishonest users
  1195.      creating bogus timestamps on their own public key certificates and
  1196.      signatures.  You can skip over this section if you are a casual user
  1197.      and aren't deeply into obscure public key protocols.
  1198.       
  1199.      There's nothing to stop a dishonest user from altering the date and
  1200.      time setting of his own system's clock, and generating his own public
  1201.      key certificates and signatures that appear to have been created at a
  1202.      different time.  He can make it appear that he signed something
  1203.      earlier or later than he actually did, or that his public/secret key
  1204.      pair was created earlier or later.  This may have some legal or
  1205.      financial benefit to him, for example by creating some kind of 
  1206.      loophole that might allow him to repudiate a signature.
  1207.       
  1208.      A remedy for this could involve some trustworthy Certifying Authority
  1209.      or notary that would create notarized signatures with a trustworthy
  1210.      timestamp.  This might not necessarily require a centralized
  1211.      authority.  Perhaps any trusted introducer or disinterested party
  1212.      could serve this function, the same way real notary publics do now. 
  1213.      A public key certificate could be signed by the notary, and the
  1214.      trusted timestamp in the notary's signature would have some legal
  1215.      significance.  The notary could enter the signed certificate into a
  1216.      special certificate log controlled by the notary.  Anyone can read
  1217.      this log. 
  1218.       
  1219.      The notary could also sign other people's signatures, creating a
  1220.      signature certificate of a signature certificate.  This would serve
  1221.      as a witness to the signature the same way real notaries do now with
  1222.      paper.  Again, the notary could enter the detached signature
  1223.      certificate (without the actual whole document that was signed) into
  1224.      a log controlled by the notary.  The notary's signature would have a
  1225.      trusted timestamp, which might have greater credibility than the
  1226.      timestamp in the original signature.  A signature becomes "legal" if
  1227.      it is signed and logged by the notary.
  1228.       
  1229.      This problem of certifying signatures with notaries and trusted
  1230.      timestamps warrants further discussion.  This can of worms will not
  1231.      be fully covered here now.  There is a good treatment of this topic
  1232.      in Denning's 1983 article in IEEE Computer (see references).  There
  1233.      is much more detail to be worked out in these various certifying
  1234.      schemes.  This will develop further as PGP usage increases and other
  1235.      public key products develop their own certifying schemes.
  1236.       
  1237.       
  1238.  
  1239.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 23
  1240.  
  1241.  
  1242.       
  1243.      A Peek Under the Hood
  1244.      =====================
  1245.       
  1246.      Let's take a look at a few internal features of PGP.
  1247.       
  1248.       
  1249.      Random Numbers
  1250.      --------------
  1251.       
  1252.      PGP uses a cryptographically strong pseudorandom number generator for
  1253.      creating temporary conventional session keys.  The seed file for this
  1254.      is called  "randseed.bin".  It too can be kept in whatever directory
  1255.      is indicated by the PGPPATH environmental variable.  If this random
  1256.      seed file does not exist, it is automatically created and seeded with
  1257.      truly random numbers derived from timing your keystroke latencies.  
  1258.       
  1259.      This generator reseeds the disk file each time it is used by mixing
  1260.      in new key material partially derived with the time of day and other
  1261.      truly random sources.  It uses the conventional encryption algorithm
  1262.      as an engine for the random number generator.  The seed file contains
  1263.      both random seed material and random key material to key the
  1264.      conventional encryption engine for the random generator.
  1265.       
  1266.      This random seed file should be at least slightly protected from
  1267.      disclosure, to reduce the risk of an attacker deriving your next or
  1268.      previous session keys.  The attacker would have a very hard time
  1269.      getting anything useful from capturing this random seed file, because
  1270.      the file is cryptographically laundered before and after each use. 
  1271.      Nonetheless, it seems prudent to at least try to keep it from falling
  1272.      into the wrong hands.
  1273.       
  1274.      If you feel uneasy about trusting any algorithmically derived random
  1275.      number source however strong, keep in mind that you already trust the
  1276.      strength of the same conventional cipher to protect your messages. 
  1277.      If it's strong enough for that, then it should be strong enough to
  1278.      use as a source of random numbers for temporary session keys.  Note
  1279.      that PGP still uses truly random numbers from physical sources
  1280.      (mainly keyboard timings) to generate long-term public/secret key
  1281.      pairs.
  1282.       
  1283.       
  1284.       
  1285.      PGP's Conventional Encryption Algorithm
  1286.      ---------------------------------------
  1287.       
  1288.      As described earlier, PGP "bootstraps" into a conventional single-key
  1289.      encryption algorithm by using a public key algorithm to encipher the
  1290.      conventional session key and then switching to fast conventional
  1291.      cryptography.  So let's talk about this conventional encryption
  1292.      algorithm.  It isn't the DES.
  1293.       
  1294.      The Federal Data Encryption Standard (DES) is a good algorithm for
  1295.      most commercial applications.  However, the Government does not trust
  1296.      the DES to protect its own classified data.  Perhaps this is because
  1297.      the DES key length is 56 bits, short enough for a brute force attack
  1298.  
  1299.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 24
  1300.  
  1301.  
  1302.      with a special purpose machine built from massive numbers of DES
  1303.      chips.  Also, Biham and Shamir have had some success recently on
  1304.      attacking the full 16-round DES.
  1305.       
  1306.      PGP does not use the DES as its conventional single-key algorithm to
  1307.      encrypt messages.  Instead, PGP uses a different conventional
  1308.      single-key block encryption algorithm, called IDEA(tm).  A future
  1309.      version of PGP may support the DES as an option, if enough users
  1310.      ask for it.  But I suspect IDEA is better than DES.
  1311.       
  1312.      For the cryptographically curious, the IDEA cipher has a 64-bit block
  1313.      size for the plaintext and the ciphertext.  It uses a key size of 128
  1314.      bits.  It is based on the design concept of "mixing operations from
  1315.      different algebraic groups".  It runs much faster in software than
  1316.      the DES.  Like the DES, it can be used in cipher feedback (CFB) and
  1317.      cipher block chaining (CBC) modes.  PGP uses it in 64-bit CFB mode.
  1318.       
  1319.      The IPES/IDEA block cipher was developed at ETH in Zurich by James L.
  1320.      Massey and Xuejia Lai, and published in 1990.  This is not a 
  1321.      "home-grown" algorithm.  Its designers have a distinguished
  1322.      reputation in the cryptologic community.  Early published papers on
  1323.      the algorithm called it IPES (Improved Proposed Encryption Standard),
  1324.      but they later changed the name to IDEA (International Data
  1325.      Encryption Algorithm).  So far, IDEA has resisted attack much better
  1326.      than other ciphers such as FEAL, REDOC-II, LOKI, Snefru and Khafre. 
  1327.      And preliminary evidence suggests that IDEA may be more resistant
  1328.      than the DES to Biham & Shamir's highly successful differential
  1329.      cryptanalysis attack.  Biham and Shamir have been examining the IDEA
  1330.      cipher for weaknesses, without success.  Academic cryptanalyst groups
  1331.      in Belgium, England, and Germany are also attempting to attack it, as
  1332.      well as the military services from several European countries.  As
  1333.      this new cipher continues to attract attack efforts from the most
  1334.      formidable quarters of the cryptanalytic world, confidence in IDEA is
  1335.      growing with the passage of time.
  1336.       
  1337.      A famous hockey player once said, "I try to skate to where I think
  1338.      the puck will be."  A lot of people are starting to feel that the
  1339.      days are numbered for the DES.  I'm skating toward IDEA.
  1340.       
  1341.      It is not ergonomically practical to use pure RSA with large keys to
  1342.      encrypt and decrypt long messages.  Absolutely no one does it that way
  1343.      in the real world.  But perhaps you are concerned that the whole
  1344.      package is weakened if we use a hybrid public-key and conventional
  1345.      scheme just to speed things up.  After all, a chain is only as strong
  1346.      as its weakest link.  Many people less experienced in cryptography
  1347.      mistakenly believe that RSA is intrinsically stronger than any
  1348.      conventional cipher.  It's not.  RSA can be made weak by using weak
  1349.      keys, and conventional ciphers can be made strong by choosing good
  1350.      algorithms.  It's usually difficult to tell exactly how strong a good
  1351.      conventional cipher is, without actually cracking it.  A really good
  1352.      conventional cipher might possibly be harder to crack than even a
  1353.      "military grade" RSA key.  The attraction of public key cryptography
  1354.      is not because it is intrinsically stronger than a conventional
  1355.      cipher-- its appeal is because it helps you manage keys more
  1356.      conveniently.
  1357.       
  1358.  
  1359.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 25
  1360.  
  1361.  
  1362.       
  1363.       
  1364.      Data Compression
  1365.      ----------------
  1366.       
  1367.      PGP normally compresses the plaintext before encrypting it.  It's too
  1368.      late to compress it after it has been encrypted; encrypted data is
  1369.      incompressible.  Data compression saves modem transmission time and
  1370.      disk space and more importantly strengthens cryptographic security.  
  1371.      Most cryptanalysis techniques exploit redundancies found in the
  1372.      plaintext to crack the cipher.  Data compression reduces this
  1373.      redundancy in the plaintext, thereby greatly enhancing resistance to 
  1374.      cryptanalysis.  It takes extra time to compress the plaintext, but 
  1375.      from a security point of view it seems worth it, at least in my 
  1376.      cautious opinion. 
  1377.       
  1378.      Files that are too short to compress or just don't compress well are
  1379.      not compressed by PGP.  
  1380.       
  1381.      If you prefer, you can use PKZIP to compress the plaintext before
  1382.      encrypting it.  PKZIP is a widely-available and effective MSDOS
  1383.      shareware compression utility from PKWare, Inc.  Or you can use ZIP,
  1384.      a PKZIP-compatible freeware compression utility on Unix and other
  1385.      systems, available from Jean-Loup Gailly.  There is some advantage in
  1386.      using PKZIP or ZIP in certain cases, because unlike PGP's built-in
  1387.      compression algorithm, PKZIP and ZIP have the nice feature of
  1388.      compressing multiple files into a single compressed file, which is
  1389.      reconstituted again into separate files when decompressed.  PGP will
  1390.      not try to compress a plaintext file that has already been
  1391.      compressed.  After decrypting, the recipient can decompress the
  1392.      plaintext with PKUNZIP.  If the decrypted plaintext is a PKZIP
  1393.      compressed file, PGP automatically recognizes this and advises the 
  1394.      recipient that the decrypted plaintext appears to be a PKZIP file.
  1395.       
  1396.      For the technically curious readers, the current version of PGP uses
  1397.      the freeware ZIP compression routines written by Jean-loup Gailly,
  1398.      Mark Adler, and Richard B. Wales.  This ZIP software uses
  1399.      functionally-equivalent compression algorithms as those used by
  1400.      PKWare's new PKZIP 2.0.  This ZIP compression software was selected
  1401.      for PGP mainly because of its free portable C source code
  1402.      availability, and because it has a really good compression ratio, and
  1403.      because it's fast.  
  1404.       
  1405.      Peter Gutmann has also written a nice compression utility called
  1406.      HPACK, available for free from many Internet FTP sites.  It encrypts
  1407.      the compressed archives, using PGP data formats and key rings.  He
  1408.      wanted me to mention that here.
  1409.       
  1410.       
  1411.       
  1412.      Message Digests and Digital Signatures
  1413.      --------------------------------------
  1414.       
  1415.      To create a digital signature, PGP encrypts with your secret key. 
  1416.      But PGP doesn't actually encrypt your entire message with your secret
  1417.      key-- that would take too long.  Instead, PGP encrypts a "message
  1418.  
  1419.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 26
  1420.  
  1421.  
  1422.      digest".  
  1423.       
  1424.      The message digest is a compact (128 bit) "distillate" of your
  1425.      message, similar in concept to a checksum.  You can also think of it
  1426.      as a "fingerprint" of the message.  The message digest "represents"
  1427.      your message, such that if the message were altered in any way, a
  1428.      different message digest would be computed from it.  This makes it
  1429.      possible to detect any changes made to the message by a forger.  A
  1430.      message digest is computed using a cryptographically strong one-way
  1431.      hash function of the message.  It would be computationally infeasible
  1432.      for an attacker to devise a substitute message that would produce an
  1433.      identical message digest.  In that respect, a message digest is much
  1434.      better than a checksum, because it is easy to devise a different
  1435.      message that would produce the same checksum.  But like a checksum,
  1436.      you can't derive the original message from its message digest.  
  1437.       
  1438.      A message digest alone is not enough to authenticate a message.  The
  1439.      message digest algorithm is publicly known, and does not require
  1440.      knowledge of any secret keys to calculate.  If all we did was attach
  1441.      a message digest to a message, then a forger could alter a message
  1442.      and simply attach a new message digest calculated from the new
  1443.      altered message.  To provide real authentication, the sender has to
  1444.      encrypt (sign) the message digest with his secret key.  
  1445.       
  1446.      A message digest is calculated from the message by the sender.  The
  1447.      sender's secret key is used to encrypt the message digest and an
  1448.      electronic timestamp, forming a digital signature, or signature
  1449.      certificate.  The sender sends the digital signature along with the
  1450.      message.  The receiver receives the message and the digital
  1451.      signature, and recovers the original message digest from the digital
  1452.      signature by decrypting it with the sender's public key.  The
  1453.      receiver computes a new message digest from the message, and checks
  1454.      to see if it matches the one recovered from the digital signature.  If
  1455.      it matches, then that proves the message was not altered, and it came
  1456.      from the sender who owns the public key used to check the signature.
  1457.       
  1458.      A potential forger would have to either produce an altered message
  1459.      that produces an identical message digest (which is infeasible), or
  1460.      he would have to create a new digital signature from a different
  1461.      message digest (also infeasible, without knowing the true sender's
  1462.      secret key).
  1463.       
  1464.      Digital signatures prove who sent the message, and that the message
  1465.      was not altered either by error or design.  It also provides
  1466.      non-repudiation, which means the sender cannot easily disavow his
  1467.      signature on the message.
  1468.       
  1469.      Using message digests to form digital signatures has other advantages
  1470.      besides being faster than directly signing the entire actual message
  1471.      with the secret key.  Using message digests allows signatures to be
  1472.      of a standard small fixed size, regardless of the size of the actual
  1473.      message.  It also allows the software to check the message integrity
  1474.      automatically, in a manner similar to using checksums.  And it allows
  1475.      signatures to be stored separately from messages, perhaps even in a
  1476.      public archive, without revealing sensitive information about the
  1477.      actual messages, because no one can derive any message content from a
  1478.  
  1479.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 27
  1480.  
  1481.  
  1482.      message digest.
  1483.       
  1484.      The message digest algorithm used here is the MD5 Message Digest
  1485.      Algorithm, placed in the public domain by RSA Data Security, Inc.
  1486.      MD5's designer, Ronald Rivest, writes this about MD5:
  1487.       
  1488.      "It is conjectured that the difficulty of coming up with two messages
  1489.      having the same message digest is on the order of 2^64 operations,
  1490.      and that the difficulty of coming up with any message having a given
  1491.      message digest is on the order of 2^128 operations.  The MD5
  1492.      algorithm has been carefully scrutinized for weaknesses.  It is,
  1493.      however, a relatively new algorithm and further security analysis is
  1494.      of course justified, as is the case with any new proposal of this
  1495.      sort.  The level of security provided by MD5 should be sufficient for
  1496.      implementing very high security hybrid digital signature schemes
  1497.      based on MD5 and the RSA public-key cryptosystem."
  1498.       
  1499.       
  1500.       
  1501.      Compatibility with Previous Versions of PGP
  1502.      ===========================================
  1503.       
  1504.      I'm sorry, PGP version 2.0 is not compatible with PGP version 1.0.  
  1505.      If you have keys generated with version 1.0, you will have to
  1506.      generate new keys to use with this version.  This version of PGP uses
  1507.      all new algorithms for conventional cryptography, compression, and
  1508.      message digests, as well as using a much better approach to key
  1509.      management.  There were just too many changes to make it compatible
  1510.      with the old format messages, signatures, and keys.  Perhaps we could
  1511.      have provided a special conversion utility to convert old keys into
  1512.      new keys, but we were all tired and wanted to get the new release out
  1513.      the door.  Besides, converting the old keys into new keys would
  1514.      probably create more problems than it would solve, because we have
  1515.      changed to a new recommended uniform style for the user ID that
  1516.      includes the full name and E-mail address in a particular syntax.
  1517.       
  1518.      There is compatibility from version 2.0 to higher versions.  Because
  1519.      new features are added, older versions may not always be able to
  1520.      handle some files created with newer versions. 
  1521.       
  1522.      We made some effort to design the internal data structures of this
  1523.      version of PGP to be adaptable to future changes, so that hopefully
  1524.      you will not be required to discard and regenerate your keys in future
  1525.      versions.
  1526.       
  1527.       
  1528.  
  1529.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 28
  1530.  
  1531.  
  1532.       
  1533.      Vulnerabilities
  1534.      ===============
  1535.       
  1536.      No data security system is impenetrable.  PGP can be circumvented in
  1537.      a variety of ways.  In any data security system, you have to ask
  1538.      yourself if the information you are trying to protect is more
  1539.      valuable to your attacker than the cost of the attack.  This should
  1540.      lead you to protecting yourself from the cheapest attacks, while not
  1541.      worrying about the more expensive attacks.  
  1542.       
  1543.      Some of the discussion that follows may seem unduly paranoid, but
  1544.      such an attitude is appropriate for a reasonable discussion of
  1545.      vulnerability issues. 
  1546.       
  1547.       
  1548.      Compromised Pass Phrase and Secret Key
  1549.      --------------------------------------
  1550.       
  1551.      Probably the simplest attack is if you leave your pass phrase for
  1552.      your secret key written down somewhere.  If someone gets it and also
  1553.      gets your secret key file, they can read your messages and make
  1554.      signatures in your name.  
  1555.       
  1556.      Don't use obvious passwords that can be easily guessed, such as the
  1557.      names of your kids or spouse.  If you make your pass phrase a single
  1558.      word, it can be easily guessed by having a computer try all the words
  1559.      in the dictionary until it finds your password.  That's why a pass
  1560.      phrase is so much better than a password.  A more sophisticated
  1561.      attacker may have his computer scan a book of famous quotations to
  1562.      find your pass phrase.  An easy to remember but hard to guess pass
  1563.      phrase can be easily constructed by some creatively nonsensical
  1564.      sayings or very obscure literary quotes.  
  1565.       
  1566.      For further details, see the section "How to Protect Secret Keys from
  1567.      Disclosure" in the Essential Topics volume of the PGP User's Guide.
  1568.       
  1569.       
  1570.      Public Key Tampering
  1571.      --------------------
  1572.       
  1573.      A major vulnerability exists if public keys are tampered with.  This
  1574.      may be the most crucially important vulnerability of a public key
  1575.      cryptosystem, in part because most novices don't immediately
  1576.      recognize it.  The importance of this vulnerability, and appropriate
  1577.      hygienic countermeasures, are detailed in the section "How to Protect
  1578.      Public Keys from Tampering" in the Essential Topics volume.    
  1579.       
  1580.      To summarize:  When you use someone's public key, make certain it has
  1581.      not been tampered with.  A new public key from someone else should be
  1582.      trusted only if you got it directly from its owner, or if it has been
  1583.      signed by someone you trust.  Make sure no one else can tamper with
  1584.      your own public key ring.  Maintain physical control of both your
  1585.      public key ring and your secret key ring, preferably on your own
  1586.      personal computer rather than on a remote timesharing system.  Keep a
  1587.      backup copy of both key rings.
  1588.  
  1589.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 29
  1590.  
  1591.  
  1592.       
  1593.       
  1594.      "Not Quite Deleted" Files
  1595.      -------------------------
  1596.       
  1597.      Another potential security problem is caused by how most operating
  1598.      systems delete files.  When you encrypt a file and then delete the
  1599.      original plaintext file, the operating system doesn't actually
  1600.      physically erase the data.  It merely marks those disk blocks as
  1601.      deleted, allowing the space to be reused later.  It's sort of like
  1602.      discarding sensitive paper documents in the paper recycling bin
  1603.      instead of the paper shredder.  The disk blocks still contain the
  1604.      original sensitive data you wanted to erase, and will probably
  1605.      eventually be overwritten by new data at some point in the future. 
  1606.      If an attacker reads these deleted disk blocks soon after they have
  1607.      been deallocated, he could recover your plaintext. 
  1608.       
  1609.      In fact this could even happen accidentally, if for some reason
  1610.      something went wrong with the disk and some files were accidentally
  1611.      deleted or corrupted.  A disk recovery program may be run to recover
  1612.      the damaged files, but this often means some previously deleted files
  1613.      are resurrected along with everything else.  Your confidential files
  1614.      that you thought were gone forever could then reappear and be
  1615.      inspected by whomever is attempting to recover your damaged disk.  
  1616.      Even while you are creating the original message with a word
  1617.      processor or text editor, the editor may be creating multiple
  1618.      temporary copies of your text on the disk, just because of its
  1619.      internal workings.  These temporary copies of your text are deleted
  1620.      by the word processor when it's done, but these sensitive fragments
  1621.      are still on your disk somewhere.  
  1622.       
  1623.      Let me tell you a true horror story.  I had a friend, married with
  1624.      young children, who once had a brief and not very serious affair. 
  1625.      She wrote a letter to her lover on her word processor, and deleted
  1626.      the letter after she sent it.  Later, after the affair was over, the
  1627.      floppy disk got damaged somehow and she had to recover it because it
  1628.      contained other important documents.  She asked her husband to
  1629.      salvage the disk, which seemed perfectly safe because she knew she
  1630.      had deleted the incriminating letter.  Her husband ran a commercial
  1631.      disk recovery software package to salvage the files.  It recovered
  1632.      the files alright, including the deleted letter.  He read it, which 
  1633.      set off a tragic chain of events.  
  1634.       
  1635.      The only way to prevent the plaintext from reappearing is to somehow
  1636.      cause the deleted plaintext files to be overwritten.  Unless you know
  1637.      for sure that all the deleted disk blocks will soon be reused, you
  1638.      must take positive steps to overwrite the plaintext file, and also
  1639.      any fragments of it on the disk left by your word processor.  You can
  1640.      overwrite the original plaintext file after encryption by using the
  1641.      PGP -w (wipe) option.  You can take care of any fragments of the
  1642.      plaintext left on the disk by using any of the disk utilities
  1643.      available that can overwrite all of the unused blocks on a disk.  For
  1644.      example, the Norton Utilities for MSDOS can do this.
  1645.       
  1646.      Even if you overwrite the plaintext data on the disk, it may still be
  1647.      possible for a resourceful and determined attacker to recover the
  1648.  
  1649.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 30
  1650.  
  1651.  
  1652.      data.  Faint magnetic traces of the original data remain on the disk
  1653.      after it has been overwritten.  Special sophisticated disk recovery
  1654.      hardware can sometimes be used to recover the data.
  1655.       
  1656.       
  1657.      Viruses and Trojan Horses
  1658.      -------------------------
  1659.       
  1660.      Another attack could involve a specially-tailored hostile computer
  1661.      virus or worm that might infect PGP or your operating system.  This
  1662.      hypothetical virus could be designed to capture your pass phrase or
  1663.      secret key or deciphered messages, and covertly write the captured
  1664.      information to a file or send it through a network to the virus's
  1665.      owner.  Or it might alter PGP's behavior so that signatures are not
  1666.      properly checked.  This attack is cheaper than cryptanalytic attacks.
  1667.       
  1668.      Defending against this falls under the category of defending against
  1669.      viral infection generally.  There are some moderately capable
  1670.      anti-viral products commercially available, and there are hygienic
  1671.      procedures to follow that can greatly reduce the chances of viral
  1672.      infection.  A complete treatment of anti-viral and anti-worm
  1673.      countermeasures is beyond the scope of this document.  PGP has no
  1674.      defenses against viruses, and assumes your own personal computer is a
  1675.      trustworthy execution environment.  If such a virus or worm actually
  1676.      appeared, hopefully word would soon get around warning everyone.  
  1677.       
  1678.      Another similar attack involves someone creating a clever imitation
  1679.      of PGP that behaves like PGP in most respects, but doesn't work the
  1680.      way it's supposed to.  For example, it might be deliberately crippled
  1681.      to not check signatures properly, allowing bogus key certificates to
  1682.      be accepted.  This "Trojan horse" version of PGP is not hard for an
  1683.      attacker to create, because PGP source code is widely available, so
  1684.      anyone could modify the source code and produce a lobotomized zombie
  1685.      imitation PGP that looks real but does the bidding of its diabolical
  1686.      master.  This Trojan horse version of PGP could then be widely
  1687.      circulated, claiming to be from me.  How insidious.
  1688.       
  1689.      You should make an effort to get your copy of PGP from a reliable
  1690.      source, whatever that means.  Or perhaps from more than one
  1691.      independent source, and compare them with a file comparison utility.
  1692.       
  1693.      There are other ways to check PGP for tampering, using digital
  1694.      signatures.  If someone you trust signs the executable version of
  1695.      PGP, vouching for the fact that it has not been infected or tampered
  1696.      with, you can be reasonably sure that you have a good copy.  You
  1697.      could use an earlier trusted version of PGP to check the signature on
  1698.      a later suspect version of PGP.  But this will not help at all if
  1699.      your operating system is infected, nor will it detect if your
  1700.      original copy of PGP.EXE has been maliciously altered in such a way
  1701.      as to compromise its own ability to check signatures.  This test also
  1702.      assumes that you have a good trusted copy of the public key that you
  1703.      use to check the signature on the PGP executable.
  1704.       
  1705.       
  1706.      Physical Security Breach
  1707.      ------------------------
  1708.  
  1709.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 31
  1710.  
  1711.  
  1712.       
  1713.      A physical security breach may allow someone to physically acquire
  1714.      your plaintext files or printed messages.  A determined opponent
  1715.      might accomplish this through burglary, trash-picking, unreasonable
  1716.      search and seizure, or bribery, blackmail or infiltration of your
  1717.      staff.  Some of these attacks may be especially feasible against
  1718.      grassroots political organizations that depend on a largely volunteer
  1719.      staff.  It has been widely reported in the press that the FBI's
  1720.      COINTELPRO program used burglary, infiltration, and illegal bugging
  1721.      against antiwar and civil rights groups.  And look what happened at
  1722.      the Watergate Hotel.  
  1723.       
  1724.      Don't be lulled into a false sense of security just because you have
  1725.      a cryptographic tool.  Cryptographic techniques protect data only
  1726.      while it's encrypted-- direct physical security violations can still
  1727.      compromise plaintext data or written or spoken information.  
  1728.       
  1729.      This kind of attack is cheaper than cryptanalytic attacks on PGP.
  1730.       
  1731.       
  1732.      Tempest Attacks
  1733.      ---------------
  1734.       
  1735.      Another kind of attack that has been used by well-equipped opponents
  1736.      involves the remote detection of the electromagnetic signals from
  1737.      your computer.  This expensive and somewhat labor-intensive attack is
  1738.      probably still cheaper than direct cryptanalytic attacks.  An
  1739.      appropriately instrumented van can park near your office and remotely
  1740.      pick up all of your keystrokes and messages displayed on your
  1741.      computer video screen.  This would compromise all of your passwords,
  1742.      messages, etc.  This attack can be thwarted by properly shielding all
  1743.      of your computer equipment and network cabling so that it does not
  1744.      emit these signals.  This shielding technology is known as "Tempest",
  1745.      and is used by some Government agencies and defense contractors.  
  1746.      There are hardware vendors who supply Tempest shielding commercially,
  1747.      although it may be subject to some kind of Government licensing.  Now
  1748.      why do you suppose the Government would restrict access to Tempest
  1749.      shielding?
  1750.       
  1751.       
  1752.      Exposure on Multi-user Systems
  1753.      ------------------------------
  1754.       
  1755.      PGP was originally designed for a single-user MSDOS machine under
  1756.      your direct physical control.  I run PGP at home on my own PC, and
  1757.      unless someone breaks into my house or monitors my electromagnetic
  1758.      emissions, they probably can't see my plaintext files or secret keys. 
  1759.       
  1760.      But now PGP also runs on multi-user systems such as Unix and VAX/VMS.
  1761.      On multi-user systems, there are much greater risks of your plaintext
  1762.      or keys or passwords being exposed.  The Unix system administrator or
  1763.      a clever intruder can read your plaintext files, or perhaps even use
  1764.      special software to covertly monitor your keystrokes or read what's
  1765.      on your screen.  On a Unix system, any other user can read your
  1766.      environment information remotely by simply using the Unix "ps"
  1767.      command.  Similar problems exist for MSDOS machines connected on a
  1768.  
  1769.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 32
  1770.  
  1771.  
  1772.      local area network.  The actual security risk is dependent on your
  1773.      particular situation.  Some multi-user systems may be safe because
  1774.      all the users are trusted, or because they have system security
  1775.      measures that are safe enough to withstand the attacks available to
  1776.      the intruders, or because there just aren't any sufficiently
  1777.      interested intruders.  Some Unix systems are safe because they are
  1778.      only used by one user-- there are even some notebook computers
  1779.      running Unix.  It would be unreasonable to simply exclude PGP from
  1780.      running on all Unix systems.
  1781.       
  1782.      PGP is not designed to protect your data while it is in plaintext
  1783.      form on a compromised system.  Nor can it prevent an intruder from
  1784.      using sophisticated measures to read your secret key while it is
  1785.      being used.  You will just have to recognize these risks on
  1786.      multi-user systems, and adjust your expectations and behavior
  1787.      accordingly.  Perhaps your situation is such that you should consider
  1788.      only running PGP on an isolated single-user system under your direct
  1789.      physical control.  That's what I do, and that's what I recommend.
  1790.       
  1791.       
  1792.      Traffic Analysis
  1793.      ----------------
  1794.       
  1795.      Even if the attacker cannot read the contents of your encrypted
  1796.      messages, he may be able to infer at least some useful information by
  1797.      observing where the messages come from and where they are going, the
  1798.      size of the messages, and the time of day the messages are sent. 
  1799.      This is analogous to the attacker looking at your long distance phone
  1800.      bill to see who you called and when and for how long, even though the
  1801.      actual content of your calls is unknown to the attacker.  This is
  1802.      called traffic analysis.  PGP alone does not protect against traffic
  1803.      analysis.  Solving this problem would require specialized 
  1804.      communication protocols designed to reduce exposure to traffic
  1805.      analysis in your communication environment, possibly with some
  1806.      cryptographic assistance.
  1807.       
  1808.       
  1809.      Cryptanalysis
  1810.      -------------
  1811.       
  1812.      An expensive and formidable cryptanalytic attack could possibly be
  1813.      mounted by someone with vast supercomputer resources, such as a
  1814.      Government intelligence agency.  They might crack your RSA key by
  1815.      using some new secret factoring breakthrough.  Perhaps so, but it is
  1816.      noteworthy that the US Government trusts the RSA algorithm enough in
  1817.      some cases to use it to protect its own nuclear weapons, according to
  1818.      Ron Rivest.  And civilian academia has been intensively attacking it
  1819.      without success since 1978. 
  1820.       
  1821.      Perhaps the Government has some classified methods of cracking the
  1822.      IDEA(tm) conventional encryption algorithm used in PGP.  This is
  1823.      every cryptographer's worst nightmare.  There can be no absolute
  1824.      security guarantees in practical cryptographic implementations.  
  1825.       
  1826.      Still, some optimism seems justified.  The IDEA algorithm's designers
  1827.      are among the best cryptographers in Europe.  It has had extensive
  1828.  
  1829.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 33
  1830.  
  1831.  
  1832.      security analysis and peer review from some of the best cryptanalysts
  1833.      in the unclassified world.  It appears to have some design advantages
  1834.      over the DES in withstanding differential cryptanalysis, which has
  1835.      been used to crack the DES.  
  1836.       
  1837.      Besides, even if this algorithm has some subtle unknown weaknesses,
  1838.      PGP compresses the plaintext before encryption, which should greatly
  1839.      reduce those weaknesses.  The computational workload to crack it is
  1840.      likely to be much more expensive than the value of the message.
  1841.       
  1842.      If your situation justifies worrying about very formidable attacks of
  1843.      this caliber, then perhaps you should contact a data security
  1844.      consultant for some customized data security approaches tailored to
  1845.      your special needs.  Boulder Software Engineering, whose address and
  1846.      phone are given at the end of this document, can provide such
  1847.      services.
  1848.       
  1849.       
  1850.      In summary, without good cryptographic protection of your data
  1851.      communications, it may have been practically effortless and perhaps
  1852.      even routine for an opponent to intercept your messages, especially
  1853.      those sent through a modem or E-mail system.  If you use PGP and
  1854.      follow reasonable precautions, the attacker will have to expend far
  1855.      more effort and expense to violate your privacy. 
  1856.       
  1857.      If you protect yourself against the simplest attacks, and you feel
  1858.      confident that your privacy is not going to be violated by a
  1859.      determined and highly resourceful attacker, then you'll probably be
  1860.      safe using PGP.  PGP gives you Pretty Good Privacy.
  1861.       
  1862.       
  1863.  
  1864.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 34
  1865.  
  1866.  
  1867.       
  1868.      Legal Issues
  1869.      ============
  1870.       
  1871.       
  1872.      Trademarks, Copyrights, and Warranties
  1873.      --------------------------------------
  1874.       
  1875.      "Pretty Good Privacy", "Phil's Pretty Good Software", and the "Pretty
  1876.      Good" label for computer software and hardware products are all
  1877.      trademarks of Philip Zimmermann and Phil's Pretty Good Software.  PGP
  1878.      is (c) Copyright Philip R. Zimmermann, 1990-1993.  Philip Zimmermann
  1879.      also holds the copyright for the PGP User's Manual, as well as any
  1880.      foreign language translations of the manual or the software.
  1881.       
  1882.      The author assumes no liability for damages resulting from the use of
  1883.      this software, even if the damage results from defects in this
  1884.      software, and makes no representations concerning the merchantability
  1885.      of this software or its suitability for any specific purpose.  It is
  1886.      provided "as is" without express or implied warranty of any kind.
  1887.       
  1888.       
  1889.      Patent Rights on the Algorithms
  1890.      -------------------------------
  1891.       
  1892.      The RSA public key cryptosystem was developed at MIT, which holds a
  1893.      patent on it (U.S. patent #4,405,829, issued 20 Sep 1983).  A company
  1894.      in California called Public Key Partners (PKP) holds the exclusive
  1895.      commercial license to sell and sub-license the RSA public key
  1896.      cryptosystem.  
  1897.       
  1898.      PKP has not granted a patent license for anyone to use their RSA
  1899.      algorithm in PGP.  The author of this software implementation of the
  1900.      RSA algorithm is providing this implementation for educational use
  1901.      only.  Licensing this algorithm from PKP is the responsibility of
  1902.      you, the user, not the author.  The author assumes no liability for
  1903.      any patent infringement that may result from executing the RSA
  1904.      algorithm on the user's computer without a license from the RSA
  1905.      patent holder.
  1906.       
  1907.      Non-US users should note that the RSA patent does not apply outside
  1908.      the US, and there is no RSA patent in any other country.  Federal
  1909.      agencies may use it because the Government paid for the development
  1910.      of RSA with grants from the National Science Foundation and the
  1911.      Navy.  And companies that have already licensed the patent from PKP
  1912.      may be able to use PGP, depending on the terms of their license. 
  1913.       
  1914.      I wrote my PGP software from scratch, with my own independently
  1915.      developed implementation of the RSA algorithm.  Before publishing
  1916.      PGP, I got a formal written legal opinion from a patent attorney with
  1917.      extensive experience in software patents.  I'm convinced that
  1918.      publishing PGP the way I did does not violate patent law.
  1919.       
  1920.      Not only did PKP acquire the exclusive patent rights for the RSA
  1921.      cryptosystem, but they also acquired the exclusive rights to three
  1922.      other patents covering other public key schemes invented by others at
  1923.  
  1924.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 35
  1925.  
  1926.  
  1927.      Stanford University, also developed with Federal funding.  This
  1928.      essentially gives one company a legal lock in the USA on nearly all
  1929.      practical public key cryptosystems.  They even appear to be claiming
  1930.      patent rights on the very concept of public key cryptography,
  1931.      regardless of what clever new original algorithms are independently
  1932.      invented by others.  I find such a comprehensive monopoly troubling,
  1933.      because I think public key cryptography is destined to become a
  1934.      crucial technology in the protection of our civil liberties and
  1935.      privacy in our increasingly connected society.  At the very least, it
  1936.      places these vital tools at risk by affording to the Government a
  1937.      single pressure point of influence.
  1938.       
  1939.      There are negotiations under way with RSA Data Security Inc (RSADSI),
  1940.      a sister company to PKP, to legalize PGP in the US.  This would be
  1941.      accomplished by integrating RSAREF into PGP.  RSAREF is a subroutine
  1942.      package from RSADSI that implements the RSA algorithm.  The RSAREF
  1943.      subroutines would have to be used instead of PGP's original
  1944.      subroutines to implement the RSA functions in PGP.  There are some
  1945.      technical obstacles to getting this done, but a solution may be found
  1946.      if the negotiations with RSADSI proceed favorably.  If RSAREF is
  1947.      integrated into PGP, it will be licensed by RSADSI for noncommercial
  1948.      usage in the US.  Foreign versions of PGP will not use RSAREF, but
  1949.      will continue to use PGP's original faster subroutine library to do
  1950.      the RSA calculations.  RSADSI may require PGP's name to change in
  1951.      order to make all this possible.  Stay tuned.
  1952.       
  1953.      It appears certain that there will be future releases of PGP,
  1954.      regardless of the outcome of licensing problems with Public Key
  1955.      Partners.  If PKP does not license PGP, then future releases of PGP
  1956.      will likely not come from me.  There are countless fans of PGP outside
  1957.      the US, and many of them are software engineers who want to improve
  1958.      PGP and promote it, regardless of what I do.  The second release of
  1959.      PGP was a joint effort of an international team of software
  1960.      engineers, implementing enhancements to the original PGP with design
  1961.      guidance from me.  It was released by Branko Lankester in The
  1962.      Netherlands and Peter Gutmann in New Zealand, out of reach of US
  1963.      patent law. Although released only in Europe and New Zealand, it
  1964.      spontaneously spread to the USA without help from me or the PGP
  1965.      development team.
  1966.       
  1967.      The IDEA(tm) conventional block cipher used by PGP is covered by a
  1968.      patent in Europe, held by ETH and a Swiss company called Ascom-Tech
  1969.      AG.  The patent number is PCT/CH91/00117.  International patents are
  1970.      pending.  IDEA(tm) is a trademark of Ascom-Tech AG.  There is no
  1971.      license fee required for noncommercial use of IDEA.  Ascom Tech AG
  1972.      has granted permission for PGP to use the IDEA cipher, and places no
  1973.      restrictions on using PGP for any purpose, including commercial use. 
  1974.      You may not extract the IDEA cipher from PGP and put it in another
  1975.      commercial product without a license.  Commercial users of IDEA may
  1976.      obtain licensing details from Dieter Profos, Ascom Tech AG, Solothurn
  1977.      Lab, Postfach 151, 4502 Solothurn, Switzerland, Tel +41 65 242885,
  1978.      Fax +41 65 235761.   
  1979.       
  1980.      The ZIP compression routines in PGP come from freeware source code,
  1981.      with the author's permission.  I'm not aware of any patents on the
  1982.      compression algorithms used in the ZIP routines, but you're welcome to
  1983.  
  1984.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 36
  1985.  
  1986.  
  1987.      check into that question yourself.
  1988.       
  1989.       
  1990.      Licensing and Distribution
  1991.      --------------------------
  1992.       
  1993.      In the USA PKP controls, through US patent law, the licensing of the
  1994.      RSA algorithm.  But I have no objection to anyone freely using or
  1995.      distributing my PGP software, without payment of fees to me.  You must
  1996.      keep the copyright notices on PGP and keep this documentation with
  1997.      it.  However, if you live in the USA, this may not satisfy any legal
  1998.      obligations you may have to PKP for using the RSA algorithm as
  1999.      mentioned above.  
  2000.       
  2001.      PGP is not shareware, it's freeware.  Forbidden freeware.  Published
  2002.      as a community service.  Giving PGP away for free will encourage far
  2003.      more people to use it, which hopefully will have a greater social
  2004.      impact.  This could lead to widespread awareness and use of the RSA
  2005.      public key cryptosystem.
  2006.       
  2007.      All the source code for PGP is available for free under the "Copyleft" 
  2008.      General Public License from the Free Software Foundation (FSF).  A
  2009.      copy of the FSF General Public License is included in the source
  2010.      release package of PGP.
  2011.       
  2012.      Regardless of and perhaps contrary to some provisions of the FSF
  2013.      General Public License, the following terms apply:
  2014.       
  2015.      1)  Written discussions of PGP in magazines or books may include
  2016.          fragments of PGP source code and documentation, without 
  2017.          restrictions.
  2018.       
  2019.      2)  Although the FSF General Public License allows non-proprietary
  2020.          derivative products, it prohibits proprietary derivative products. 
  2021.          Despite this, I may grant you a special license if you want to derive
  2022.          a proprietary commercial product from some of PGP's parts.  There may
  2023.          or may not be a fee, depending on the circumstances.  Retaining my
  2024.          copyright notice and attribution might suffice in some cases.  Give
  2025.          me a call and we'll discuss it.  I'm real easy to please.  Any such
  2026.          license would not free you of any patent licensing requirements.  
  2027.       
  2028.      Feel free to disseminate the complete PGP release package as widely
  2029.      as possible.  Give it to all your friends.  If you have access to any
  2030.      electronic Bulletin Boards Systems, please upload the complete PGP
  2031.      executable object release package to as many BBS's as possible.  You
  2032.      may disseminate the PGP source release package too, if you've got
  2033.      it.  The PGP version 2.3 executable object release package for MSDOS
  2034.      contains the PGP executable software, documentation, sample key rings
  2035.      including my own public key, and signatures for the software and this
  2036.      manual, all in one PKZIP compressed file called pgp22.zip.  The PGP
  2037.      source release package for MSDOS contains all the C source files in
  2038.      one PKZIP compressed file called pgp22src.zip.  The filename for the
  2039.      release package is derived from the version number of the release.
  2040.       
  2041.      You may obtain free copies or updates to PGP from thousands of BBS's
  2042.      worldwide or from other public sources such as Internet FTP sites. 
  2043.  
  2044.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 37
  2045.  
  2046.  
  2047.      Don't ask me for a copy directly from me, since I'd rather avoid
  2048.      further legal problems with PKP at this time.  I might be able to
  2049.      tell you where you can get it, however.  
  2050.       
  2051.      After all this work I have to admit I wouldn't mind getting some fan
  2052.      mail for PGP, to gauge its popularity.  Let me know what you think
  2053.      about it and how many of your friends use it.  Bug reports and
  2054.      suggestions for enhancing PGP are welcome, too.  Perhaps a future PGP
  2055.      release will reflect your suggestions.  
  2056.       
  2057.      This project has not been funded and the project has nearly eaten me
  2058.      alive.  This means you can't count on a reply to your mail, unless
  2059.      you only need a short written reply and you include a stamped
  2060.      self-addressed envelope.  But I do reply to E-mail.  Please keep it in
  2061.      English, as my foreign language skills are weak.  If you call and I'm
  2062.      not in, it's best to just try again later.  I usually don't return
  2063.      long distance phone calls, unless you leave a message that I can call
  2064.      you collect.  If you need any significant amount of my time, I am
  2065.      available on a paid consulting basis, and I do return those calls.
  2066.       
  2067.      The most inconvenient mail I get is for some well-intentioned person
  2068.      to send me a few dollars asking me for a copy of PGP.  I don't send 
  2069.      it to them because I'd rather avoid any legal problems with PKP.  Or
  2070.      worse, sometimes these requests are from foreign countries, and I
  2071.      would be risking a violation of US cryptographic export control
  2072.      laws.  Even if there were no legal hassles involved in sending PGP to
  2073.      them, they usually don't send enough money to make it worth my time.
  2074.      I'm just not set up as a low cost low volume mail order business.  I
  2075.      can't just ignore the request and keep the money, because they
  2076.      probably regard the money as a fee for me to fulfill their request.
  2077.      If I return the money, I might have to get in my car and drive down
  2078.      to the post office and buy some postage stamps, because these
  2079.      requests rarely include a stamped self-addressed envelope.  And I
  2080.      have to take the time to write a polite reply that I can't do it.  If
  2081.      I postpone the reply and set the letter down on my desk, it might be
  2082.      buried within minutes and won't see the light of day again for
  2083.      months.  Multiply these minor inconveniences by the number of
  2084.      requests I get, and you can see the problem.  Isn't it enough that
  2085.      the software is free?  It would be nicer if people could try to get
  2086.      PGP from any of the myriad other sources.  If you don't have a modem,
  2087.      ask a friend to get it for you.  If you can't find it yourself, I
  2088.      don't mind answering a quick phone call. 
  2089.       
  2090.      If anyone wants to volunteer to improve PGP, please let me know.  It
  2091.      could certainly use some more work.  Some features were deferred to
  2092.      get it out the door.  A number of PGP users have since donated their
  2093.      time to port PGP to Unix on Sun SPARCstations, to Ultrix, to VAX/VMS,
  2094.      to OS/2, to the Amiga, and to the Atari ST.  Perhaps you can help
  2095.      port it to some new environments.  But please let me know if you plan
  2096.      to port or add enhancements to PGP, to avoid duplication of effort,
  2097.      and to avoid starting with an obsolete version of the source code.  
  2098.       
  2099.      Because so many foreign language translations of PGP have been
  2100.      produced, most of them are not distributed with the regular PGP
  2101.      release package because it would require too much disk space. 
  2102.      Separate language translation "kits" are available from a number of
  2103.  
  2104.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 38
  2105.  
  2106.  
  2107.      independent sources, and are sometimes available separately from the
  2108.      same distribution centers that carry the regular PGP release
  2109.      software.  These kits include translated versions of the file 
  2110.      LANGUAGE.TXT, PGP.HLP, and the PGP User's Guide.  If you want to
  2111.      produce a translation for your own native language, contact me first
  2112.      to get the latest information and standard guidelines, and to find
  2113.      out if it's been translated to your language already.  Colin Plumb
  2114.      (colin@nyx.cs.du.edu) maintains a comprehensive collection of foreign
  2115.      language kits from other translators. 
  2116.       
  2117.      Future versions of PGP may have to change the data formats for
  2118.      messages, signatures, keys and key rings, in order to provide
  2119.      important new features.  This may cause backward compatibility
  2120.      problems with this version of PGP.  Future releases may provide
  2121.      conversion utilities to convert old keys, but you may have to dispose
  2122.      of old messages created with the old PGP.
  2123.       
  2124.      If you have access to the Internet, watch for announcements of new
  2125.      releases of PGP on the Internet newsgroups "sci.crypt" and PGP's own
  2126.      newsgroup, "alt.security.pgp".  There is also an interest group
  2127.      mailing list called info-pgp, which is intended for users without
  2128.      access to the "alt.security.pgp" newsgroup.  Info-pgp is moderated by
  2129.      Hugh Miller, and you may subscribe to it by writing him a letter at 
  2130.      info-pgp-request@lucpul.it.luc.edu.  Include your name and Internet
  2131.      address.  If you want to know where to get PGP, Hugh can send you a
  2132.      list of Internet FTP sites and BBS phone numbers.  Hugh may also be
  2133.      reached at hmiller@lucpul.it.luc.edu. 
  2134.       
  2135.       
  2136.       
  2137.      Export Controls
  2138.      ---------------
  2139.       
  2140.      The Government has made it illegal in many cases to export good
  2141.      cryptographic technology, and that may include PGP.  They regard this
  2142.      kind of software as munitions.  This is determined by volatile State
  2143.      Department policies, not fixed laws.  I will not export this software
  2144.      out of the US or Canada in cases when it is illegal to do so under US
  2145.      State Department policies, and I assume no responsibility for other
  2146.      people exporting it on their own.
  2147.       
  2148.      If you live outside the US or Canada, I advise you not to violate US
  2149.      State Department policies by getting PGP from a US source.  Since
  2150.      thousands of domestic users got it after its initial publication, it
  2151.      somehow leaked out of the US and spread itself widely abroad, like
  2152.      dandelion seeds blowing in the wind.  If PGP has already found its
  2153.      way into your country, then I don't think you're violating US export
  2154.      law if you pick it up from a source outside of the US.  
  2155.       
  2156.      It seems to some legal observers I've talked with, that the framers of
  2157.      the US export controls never envisioned that they would ever apply to
  2158.      cryptographic freeware that has been published and scattered to the
  2159.      winds.  It's hard to imagine a US attorney trying to build a real
  2160.      case against someone for the "export" of software published freely in
  2161.      the US.  As far as anyone I've talked to knows, it's never been done,
  2162.      despite numerous examples of export violations.  I'm not a lawyer and
  2163.  
  2164.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 39
  2165.  
  2166.  
  2167.      I'm not giving you legal advice-- I'm just trying to point out what
  2168.      seems like common sense.
  2169.       
  2170.      Starting with PGP version 2.0, the release point of the software has
  2171.      been outside the US, on publicly-accessible computers in Europe.
  2172.      Each release is electronically sent back into the US and posted on
  2173.      publicly-accessible computers in the US by PGP privacy activists in
  2174.      foreign countries.  There are some restrictions in the US regarding
  2175.      the import of munitions, but I'm not aware of any cases where this
  2176.      was ever enforced for importing cryptographic software into the US. 
  2177.      I imagine that a legal action of that type would be quite a spectacle
  2178.      of controversy.
  2179.       
  2180.      Some foreign governments impose serious penalties on anyone inside
  2181.      their country for merely using encrypted communications.  In some
  2182.      countries they might even shoot you for that.  But if you live in
  2183.      that kind of country, perhaps you need PGP even more.
  2184.       
  2185.       
  2186.       
  2187.      Computer-Related Political Groups
  2188.      =================================
  2189.       
  2190.      PGP is a very political piece of software.  It seems appropriate to
  2191.      mention here some computer-related activist groups.  Full details on
  2192.      these groups, and how to join them, is provided in a separate
  2193.      document file in the PGP release package.
  2194.       
  2195.      The Electronic Frontier Foundation (EFF) was founded in July, 1990,
  2196.      to assure freedom of expression in digital media, with a particular
  2197.      emphasis on applying the principles embodied in the US Constitution
  2198.      and the Bill of Rights to computer-based communication.  They can be
  2199.      reached in Washington DC, at (202) 544-9237.  Internet E-mail address: 
  2200.      eff@eff.org.
  2201.       
  2202.      Computer Professionals For Social Responsibility (CPSR) empowers
  2203.      computer professionals and computer users to advocate for the
  2204.      responsible use of information technology and empowers all who use
  2205.      computer technology to participate in public policy debates on the
  2206.      impacts of computers on society.  They can be reached at:
  2207.      415-322-3778 in Palo Alto, E-mail address cpsr@csli.stanford.edu.
  2208.       
  2209.      The League for Programming Freedom (LPF) is a grass-roots organization
  2210.      of professors, students, businessmen, programmers and users dedicated
  2211.      to bringing back the freedom to write programs.  They regard patents
  2212.      on computer algorithms as harmful to the US software industry.  They
  2213.      can be reached at (617) 433-7071.  E-mail address: lpf@uunet.uu.net.
  2214.       
  2215.      For more details on these groups, see the accompanying document in
  2216.      the PGP release package.
  2217.       
  2218.       
  2219.  
  2220.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 40
  2221.  
  2222.  
  2223.       
  2224.      Recommended Introductory Readings
  2225.      =================================
  2226.       
  2227.      1)  Dorothy Denning, "Cryptography and Data Security", Addison-Wesley,
  2228.          Reading, MA 1982
  2229.      2)  Dorothy Denning, "Protecting Public Keys and Signature Keys",
  2230.          IEEE Computer, Feb 1983
  2231.      3)  Martin E. Hellman, "The Mathematics of Public-Key Cryptography," 
  2232.          Scientific American, Aug 1979
  2233.      4)  Steven Levy, "Crypto Rebels", WIRED, May/Jun 1993, page 54.
  2234.          (This is a "must-read" article on PGP and other related topics.)
  2235.       
  2236.      Other Readings
  2237.      ==============
  2238.       
  2239.      5)  Ronald Rivest, "The MD5 Message Digest Algorithm", MIT Laboratory
  2240.          for Computer Science, 1991
  2241.      6)  Xuejia Lai, "On the Design and Security of Block Ciphers", 
  2242.          Institute for Signal and Information Processing, ETH-Zentrum, 
  2243.          Zurich, Switzerland, 1992
  2244.      7)  Xuejia Lai, James L. Massey, Sean Murphy, "Markov Ciphers and 
  2245.          Differential Cryptanalysis", Advances in Cryptology- EUROCRYPT'91
  2246.      8)  Philip Zimmermann, "A Proposed Standard Format for RSA 
  2247.          Cryptosystems", Advances in Computer Security, Vol III, edited by
  2248.          Rein Turn, Artech House, 1988
  2249.      9)  Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and
  2250.          Source Code in C", John Wiley & Sons, 1993 (coming in November)
  2251.      10) Paul Wallich, "Electronic Envelopes", Scientific American, Feb
  2252.          1993, page 30.  (This is an article on PGP)
  2253.       
  2254.       
  2255.      To Contact the Author
  2256.      =====================
  2257.       
  2258.      Philip Zimmermann may be reached at:
  2259.       
  2260.      Boulder Software Engineering
  2261.      3021 Eleventh Street
  2262.      Boulder, Colorado 80304  USA
  2263.      Phone 303-541-0140 (voice or FAX)  (10:00am - 7:00pm Mountain Time)
  2264.      Internet:  prz@acm.org
  2265.       
  2266.       
  2267.       
  2268.  
  2269.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 41
  2270.  
  2271.  
  2272.       
  2273.      Appendix A:  Where to Get PGP
  2274.      =============================
  2275.       
  2276.      The following describes how to get the freeware public key
  2277.      cryptographic software PGP (Pretty Good Privacy) from an anonymous
  2278.      FTP site on Internet, or from other sources.  
  2279.       
  2280.      PGP has sophisticated key management, an RSA/conventional hybrid 
  2281.      encryption scheme, message digests for digital signatures, data
  2282.      compression before encryption, and good ergonomic design.  PGP is
  2283.      well featured and fast, and has excellent user documentation.  Source
  2284.      code is free.
  2285.       
  2286.      PGP uses the RSA cryptosystem which is claimed by a US patent held by
  2287.      a company called Public Key Partners.  PGP users outside the US take
  2288.      note that there is no RSA patent outside the US.  Also, bear in mind
  2289.      that there are US and Canadian export laws prohibiting anyone inside
  2290.      the US and Canada from exporting cryptographic software like this. 
  2291.      If you live outside the US, you're probably not violating US export
  2292.      law if you pick it up from a source outside of the US.  Note that due
  2293.      to negotiations with the RSA patent holders, the name of PGP may
  2294.      change in a future release.
  2295.       
  2296.      What follows is a small sample of places that allegedly have PGP, as
  2297.      of June 1993.  This information is not guaranteed to be correct.
  2298.      Some US sites have occasionally withdrawn PGP because of fear of
  2299.      legal intimidation from the RSA patent holders.
  2300.       
  2301.      There are two compressed archive files in the standard release, with
  2302.      the file name derived from the release version number.  For PGP
  2303.      version 2.3, you must get pgp23.zip which contains the MSDOS binary
  2304.      executable and the PGP User's Guide, and you can optionally get
  2305.      pgp23src.zip which contains all the source code.  These files can be
  2306.      decompressed with the MSDOS shareware archive decompression utility
  2307.      PKUNZIP.EXE, version 1.10 or later.  For Unix users who lack an
  2308.      implementation of UNZIP, the source code can also be found in the
  2309.      compressed tar file pgp23src.tar.Z.
  2310.       
  2311.      A reminder:  Set mode to binary or image when doing an FTP transfer.
  2312.      And when doing a kermit download to your PC, specify 8-bit binary
  2313.      mode at both ends.  Here are some Internet sites that have PGP via
  2314.      anonymous FTP:
  2315.          
  2316.      Finland:    nic.funet.fi  (128.214.6.100)
  2317.                  Directory: /pub/unix/security/crypt/
  2318.       
  2319.      Italy:      ghost.dsi.unimi.it  (149.132.2.1)
  2320.                  Directory: /pub/security/
  2321.       
  2322.      UK:         src.doc.ic.ac.uk
  2323.                  Directory: /computing/security/software/PGP
  2324.       
  2325.      For those lacking FTP connectivity to the net, nic.funet.fi also
  2326.      offers the files via email.  To get version 2.3, send the following
  2327.      mail message to mailserv@nic.funet.fi:
  2328.  
  2329.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 42
  2330.  
  2331.  
  2332.       
  2333.          ENCODER uuencode
  2334.          SEND pub/unix/security/crypt/pgp23src.zip
  2335.          SEND pub/unix/security/crypt/pgp23.zip
  2336.       
  2337.      This will deposit the two zipfiles, as (about) 15 batched messages in
  2338.      your mailbox within about 24 hours.  Save and uudecode.
  2339.       
  2340.      In the US, PGP may be found on God knows how many BBS systems, far
  2341.      too many to list here.  Still, if you don't have any local BBS phone
  2342.      numbers handy, here are some BBS's you might try.
  2343.       
  2344.      The GRAPEVINE BBS in Little Rock Arkansas has set up a special
  2345.      account for people to download PGP for free.  The SYSOP is Jim Wenzel,
  2346.      at jim.wenzel@grapevine.lrk.ar.us.  The following phone numbers are
  2347.      applicable and should be dialed in the order presented (i.e., the
  2348.      first one is the highest speed line):  (501) 753-6859, (501)
  2349.      753-8121, (501) 791-0124.  When asked to login use the following
  2350.      information:
  2351.       
  2352.          name: PGP USER        ('PGP' is 1st name, 'USER' is 2nd name)
  2353.          password: PGP
  2354.       
  2355.      PGP is also widely available on Fidonet, a large informal network of
  2356.      PC-based bulletin board systems interconnected via modems.  Check
  2357.      your local bulletin board systems.  It is available on many foreign
  2358.      and domestic Fidonet BBS sites.
  2359.       
  2360.      In New Zealand, try this (supposedly free) dial-up BBS system:
  2361.         Kappa Crucis:  +64 9 817-3714, -3725, -3324, -8424, -3094, -3393
  2362.       
  2363.      Source and binary distributions of PGP are available from the Canadian
  2364.      Broadcasting Corporation library, which is open to the public.  It has
  2365.      branches in Toronto, Montreal, and Vancouver.  Contact Max Allen, at
  2366.      +1 416 205-6017 if you have questions.
  2367.       
  2368.      For information on PGP implementations on the Apple Macintosh,
  2369.      Commodore Amiga, or Atari ST, or any other questions about where to
  2370.      get PGP for any other platform, contact Hugh Miller at
  2371.      hmiller@lucpul.it.luc.edu.
  2372.       
  2373.      Here are a few people and their email addresses or phone numbers you
  2374.      can contact in some countries to get information on local PGP 
  2375.      availability:
  2376.       
  2377.      Peter Gutmann                 Hugh Kennedy
  2378.      pgut1@cs.aukuni.ac.nz         70042.710@compuserve.com
  2379.      New Zealand                   Germany
  2380.       
  2381.      Branko Lankester              Miguel Angel Gallardo
  2382.      lankeste@fwi.uva.nl           gallardo@batman.fi.upm.es
  2383.      +31 2159 42242                (341) 474 38 09
  2384.      The Netherlands               Spain
  2385.       
  2386.      Hugh Miller                   Colin Plumb
  2387.      hmiller@lucpul.it.luc.edu     colin@nyx.cs.du.edu
  2388.  
  2389.      PGPDOC2.TXT             Tuesday, June 15, 1993 12:40 am             Page 43
  2390.  
  2391.  
  2392.      (312) 508-2727                Toronto, Ontario, Canada
  2393.      USA
  2394.       
  2395.      Jean-loup Gailly
  2396.      jloup@chorus.fr
  2397.      France
  2398.       
  2399.